Business Requirements Specification - California ISO · PDF fileReplacement Requirement ... plans are submitted approximately 1 month before the operating month and must demonstrate

Owner: Owens; Andrew Program Office

Copyright 2012 California ISO

Doc ID: GNFDMDEHU6BB-46-53 Page 1 of 44

Business Requirements Specification

Replacement Requirement for Scheduled Generation Outages

Document Version: 2.2

Date Created: 9/5/2013

Revision History

Date Version Description

5/29/2013 2.0 Creation of Document

8/1/2013 2.1 Addition of MSG Requirements

9/5/2013 2.2 Additional clairification added to BRQ187 Addition of BRQ208 & BRQ209




Technology

Template Version: 2.8


Replacement Requirement for Scheduled Generation Outages Business

Requirements Specification - Planning Date Created: 9/5/2013

Table of Contents

1. INTRODUCTION ........................................................................................................................................................................ 5

1.1 PURPOSE .................................................................................................................................................................................... 5 1.2 REFERENCES .............................................................................................................................................................................. 5

2. DETAILS OF BUSINESS NEED/PROBLEM .......................................................................................................................... 6

2.1 DESCRIPTION.............................................................................................................................................................................. 6

3. BUSINESS PROCESS IMPACTS .............................................................................................................................................. 7

3.1 HIGH LEVEL BUSINESS PROCESS ............................................................................................................................................... 7 3.1.1 Description ...................................................................................................................................................................... 7

3.3 JUSTIFICATION ........................................................................................................................................................................... 8

4. BUSINESS REQUIREMENTS ................................................................................................................................................... 9

4.1 BUSINESS PROCESS: SCHEDULING AND LOGGING SYSTEM FOR THE ISO OF CALIFORNIA (SLIC) – DROP 2 .............................. 9 4.1.1 Business Requirements .................................................................................................................................................... 9

4.2 BUSINESS PROCESS: DATA PREPARATION FOR RA REQUIREMENT DETERMINATION – DROP 1 ............................................... 11 4.2.1 Business Requirements .................................................................................................................................................. 11

4.3 BUSINESS PROCESS: RA PLAN UPLOAD VALIDATION MONTHLY – DROP 2 ............................................................................. 12 4.3.1 Business Requirements .................................................................................................................................................. 12

4.4 BUSINESS PROCESS: RA PLAN VALIDATION ANNUAL – DROP 1 .............................................................................................. 13 4.4.1 Business Requirements .................................................................................................................................................. 13

4.5 BUSINESS PROCESS: SUPPLY PLAN UPLOAD VALIDATION MONTHLY – DROP 2 ...................................................................... 15 4.5.1 Business Requirements .................................................................................................................................................. 15

4.6 BUSINESS PROCESS: SUPPLY PLAN UPLOAD – ANNUAL – DROP 1 ........................................................................................... 15 4.6.1 Business Requirements .................................................................................................................................................. 15

4.7 BUSINESS PROCESS: CROSS VALIDATION OF RA AND SUPPLY PLANS D RESOURCES ONLY – MONTHLY – DROP 2 ................ 16 4.7.1 Business Requirements .................................................................................................................................................. 16

4.8 BUSINESS PROCESS: CROSS VALIDATION ANNUAL PROCESS – DROP 1 ................................................................................... 17 4.8.1 Business Requirements .................................................................................................................................................. 17

4.9 BUSINESS PROCESS: OUTAGE IMPACT ANALYSIS (OIA) – DROP 2 ........................................................................................... 19 4.9.1 Business Requirements .................................................................................................................................................. 19

4.10 BUSINESS PROCESS: CAISO SYSTEM RELIABILITY MARGIN (CSRM) CHECK – DROP 2 .................................................... 20 4.10.1 Business Requirements .............................................................................................................................................. 20

4.11 BUSINESS PROCESS: SPECIFIED (S) REPLACEMENTS – DROP 2 ............................................................................................ 20 4.11.1 Business Requirements .............................................................................................................................................. 20

4.12 BUSINESS PROCESS: NON-SPECIFIED (N) REPLACEMENTS – DROP 2 ................................................................................... 24 4.12.1 Business Requirements .............................................................................................................................................. 24

4.13 BUSINESS PROCESS: MANAGEMENT OF S AND N REPLACEMENTS – DROP 2 ....................................................................... 26 4.13.1 Business Requirements .............................................................................................................................................. 26

4.14 BUSINESS PROCESS: LSE VIEW OF REPLACEMENT DATA AND ERRORS – DROP 2 ............................................................... 28 4.14.1 Business Requirements .............................................................................................................................................. 28

4.15 BUSINESS PROCESS: SUPPLIER VIEW OF REPLACEMENT DATA AND ERRORS – DROP 2 ....................................................... 29 4.15.1 Business Requirements .............................................................................................................................................. 29

4.16 BUSINESS PROCESS: RA RELATED REQUIREMENTS ............................................................................................................. 29 4.16.1 Business Requirements .............................................................................................................................................. 29

4.17 BUSINESS PROCESS: OUTAGE MANAGEMENT (OM) FROM T-45 TO T+31 – DROP 2 ........................................................... 31 4.17.1 Business Requirements .............................................................................................................................................. 31

4.18 BUSINESS PROCESS: SCHEDULING COORDINATOR TRANSFERS – DROP 2 ............................................................................ 33




Technology





4.18.1 Business Requirements .............................................................................................................................................. 33 4.19 BUSINESS PROCESS: RESOURCE ADEQUACY AVAILABILITY (RAAM) – DROP 2 ................................................................. 36

4.19.1 Business Requirements .............................................................................................................................................. 36 4.20 BUSINESS PROCESS: SETTLEMENTS – DROP 2 ..................................................................................................................... 37

4.20.1 Business Requirements .............................................................................................................................................. 37

APPENDIX A: TERMS AND DEFINITIONS ................................................................................................................................. 38

APPENDIX B: TIMELINE ................................................................................................................................................................ 39

APPENDIX C: BUSINESS PROCESS STEPS ................................................................................................................................. 40




Technology





Disclaimer All information contained in this draft Business Requirements Specification (BRS) as provided by the California Independent System Operator Corporation (ISO) is prepared for discussion and information purposes only. The draft BRS is provided “as is” without representation or warranty of any kind, including, without limitation, a representation or warranty as to accuracy, completeness, or appropriateness for any particular purpose. The draft BRS shall be revised as the development and review of the business requirements progresses. The ISO assumes no responsibility for the consequences of any errors or omissions. The ISO may revise or withdraw all or part of this information at any time at its discretion without notice.




Technology





1. Introduction

1.1 Purpose

This document describes at a high-level the business requirements the ISO proposes to implement to automate certain replacement requirement functions in response to requests by stakeholders and the ISO’s business units.. The information in this document serves as input to determine the scope of information systems projects and to all business process modeling and system requirements specifications efforts.

These requirements are intended for submission to the ISO’s program office and will serve as the initial set of business unit requirements for the appropriate software application/systems development effort. It is understood that ITS will perform additional requirements and systems analysis and may produce “To Be” business process models, system requirements specifications, and use cases to serve as the set of requirements documents used by the ITS development teams to buy, modify, or build the necessary software and hardware systems. The business unit(s) involved in the project will have an opportunity to review and approve all ITS requirements documentation produced.

This document is provided at an early stage to facilitate systems development. These requirements are subject to

change as the ISO and stakeholders develop ISO tariff provisions and such provisions are processed and accepted by

the Federal Energy Regulatory Commission, to the extent such approval is required. Market participants should consult

the ISO website for updates as this process unfolds.

1.2 References

All references represent external requirements documents or stakeholder requests developed and submitted by the ISO’s business units.

1. Policy-related documents, including the Draft Final Proposal and stakeholder comments are located on the “Replacement Requirement for Scheduled Generation Outages” stakeholder initiatives web page at: http://www.caiso.com/Documents/Replacement%20requirement%20for%20scheduled%20generation%20outages%20-%20papers%20and%20proposals

http://www.caiso.com/Documents/Replacement%20requirement%20for%20scheduled%20generation%20outages%20-%20papers%20and%20proposals

http://www.caiso.com/Documents/Replacement%20requirement%20for%20scheduled%20generation%20outages%20-%20papers%20and%20proposals




Technology





2. Details of Business Need/Problem

2.1 Description

In D.11-06-0221, the California Public Utilities Commission (CPUC) decided that, starting with the 2013 resource

adequacy (also referred to as “RA” in the tables below) year, the CPUC would no longer apply a replacement rule

requiring its jurisdictional load serving entities (also referred to as “LSEs” in the tables below) to provide replacement

resource adequacy capacity under certain circumstances when resource adequacy resources were on planned outages.

The ISO is developing changes to its outage management process and resource adequacy policy to address the

elimination of the CPUC’s resource adequacy replacement rule.




Technology





3. Business Process Impacts

3.1 High Level Business Process

3.1.1 Description

Implementing the replacement requirement for scheduled generation outages will impact the following existing business processes:

Manage reliability requirements

Manage generation outages

3.2 Description

Specific impacts on these business processes that the replacement requirement for scheduled generation outages team has identified to date are as follows:

Manage reliability requirements: One component of the replacement requirement for scheduled generation outages project is to create a business process flow to document the validation process for resource adequacy plans, outages, and supply plans. See Appendix.

Manage generation outages: The replacement requirement for scheduled generation outages project requires changes to the business process for managing generation outages, mainly related to the incorporation of the resource adequacy outage management business process.




Technology





3.3 Justification

The CPUC instituted the resource adequacy program to ensure that sufficient capacity is available to the ISO when and

where needed to maintain the reliability of the grid. The program has changed since its inception, but the basics have so

far remained unchanged: it is currently a one-year forward and monthly demonstration that LSEs have procured sufficient

capacity to meet their expected demand peak plus a 15% reserve margin for forced outages and forecast errors.

The resource adequacy program requires LSEs to submit annual and monthly resource adequacy plans. The annual

showing is submitted by LSEs in October for the following year. LSEs are required to meet two main requirements. First,

they are required to show they have procured 90% of their need for the 5 summer months of the following year.

Additionally, if their load is located in any of the Local Capacity Regions which the ISO has defined, they must

demonstrate 100% of their need for local capacity for the entire year. The local capacity showings can also count

towards the system level. The annual showing is preliminary and the LSEs can change their resources when they get to

the monthly showings.

Then, monthly resource adequacy plans are submitted approximately 1 month before the operating month and must

demonstrate the full amount of the capacity requirement for the month (i.e., 115% of the expected peak load for the

month). The Local Regulatory Authority determines if the resource adequacy showing is sufficient to meet the resource

adequacy requirements. If an LSE is deficient in its resource adequacy capacity in a monthly resource adequacy plan

and fails to cure this deficiency, the ISO may use its Capacity Procurement Mechanism to procure the needed capacity

and allocate the costs to the deficient LSE.




Technology





4. Business Requirements

The sections below describe the business processes and the associated business requirements involved in the project. These may represent high level functional, non-functional, reporting and/or infrastructure requirements. These business requirements directly relate to the high level scope items determined for the project.

4.1 Business Process: Scheduling and Logging System for the ISO of California (SLIC) – Drop 2

Describes the changes to the outage system.

4.1.1 Business Requirements

ID# Business Feature Requirement Type

Potential Application(s) Impacted

RR-BRQ001

Outage system must consume RA data. Business Rule: Outage system must obtain RA Plan data from T-45 to T-7, and include specified and non-specified replacements.

Core SLIC; RA Application

RR-BRQ002

Outage system must receive at T-7 the final RA data.


RR-BRQ003

Outage system must consume substitution and replacement data. Business Rule: Only consume approved substitutions and outage approved replacements.


RR-BRQ004

Outage system must send requested, scheduled, pending, and approved outages for the period from the showing due date to T+31 to RA systems. Business Rule: Showing due date is normally T-45. Any status changes should also be reflected.


RR-BRQ006

Outage system must have the capability to identify RA resources.

Core SLIC

RR-BRQ007

Outage system must display units on replacement. Core SLIC




Technology







RR-BRQ009

When an availability point represents an overlap of

outages, Outage system will determine the

contribution of each outage to the availability point

value by the difference between the availability

point values entered.

1. In general, the planned (or forced)

curtailment value of an outage for a

specific availability point = Sum of the

differences in revisions to an Availability

point value that can be attributed to that

outage. PLAN_CURTOTG_ID,N =

CALC_CURTOTG_ID,N +

PLAN_CURTOTG_ID,N-1

where OTG ID refers to a specific outage,

N represents the number of revisions to a

specific availability point,

CALC_CURTOTG_ID,N = AVAILN-1 – AVAILN, AVAIL represents the availability point

value and PLAN_CURTOTG_ID,0 = 0 Note: Because the planned (or forced) curtailment values are derived from the difference in the values of an availability point over time, the result may end up being a negative value. If so, Outage system will cap the value at 0 (this is in line with current outage system rules, a negative curtailment value is not allowed)

Core

SLIC

RR-BRQ010

When an outage on an RA resource is extended in

the RT timeframe, Outage system must check the

due back date and use that to determine where to

route the outage (i.e. to RT or OC).

Core

SLIC

RR-BRQ014

Proposed T-45 analysis methods

A: MCI determines system requirements, applies

outages, (approved, scheduled and pending), and

notifies Outage Management of outages that must

be approved with replacement, ranked in last-in,

first-out order.

B: MCI applies outages (approved only), applies

specified replacements for designated resources

on outage, determines ISO system peak,

compares reduced RA against the system peak to

find system short days and notifies Outage

Management of pending outages that require

Outage Management analysis.

Business Process

SLIC




Technology







RR-BRQ016

Outage system must alert a scheduling coordinator or outage management user when a request is submitted to change an outage on a resource after T-45.

Core

SLIC

RR-BRQ018

Approved short notice opportunity outages submitted less than three days prior to the start of an outage should not be automatically classified as a forced outage.

Core

SLIC

RR-BRQ019

Outage system must alert the impacted supplier if a new outage is requested on a RA resource since this outage could require a replacement.

Core

SLIC

RR-BRQ021

Outage system must identify short term opportunity outages.

Core

SLIC

RR-BRQ022

Outage system must send short term opportunity outages to RA systems.

Core

SLIC; RA Application

RR-BRQ023

Outage system must have the ability for the scheduling coordinator to provide current curtailment to be: a). stated b). updated as the outage may change

Core

SLIC

4.2 Business Process: Data Preparation for RA Requirement Determination – Drop 1

Describes the process in the resource adequacy data shall be prepared for the resource adequacy system.




RR-BRQ025

RA application must allow authorized external users to upload Annual/Monthly LD, CAM, RMR, and DR data.

Core

RA Application

RR-BRQ027

RA application must allow authorized external users to upload Annual/Monthly RA Plan data on an annual/monthly basis.

Core

RA Application

RR-BRQ029

RA application must receive replacement data associated with outages submitted from T-45 to T+31.

Core

RA Application; SLIC

RR-BRQ030

RA application must have the ability to validate LD, CAM, RMR, and DR data.

Core

RA Application




Technology





4.3 Business Process: RA Plan Upload Validation Monthly – Drop 2

Describes the resource adequacy plan upload validation on the monthly level.




RR-BRQ031

Designated (D) and physical resources internal to the ISO BAA resources must be provided for the full RA month.

Core Tariff BPM

RA Application

RR-BRQ032

Specified (S) resources must be provided for a minimum of a full day during the RA month. Business Rule: Start time should be 00:00:00 to 23:59:59 (end time). These should be contiguous full days.

Core Tariff BPM

RA Application

RR-BRQ033

Non-specified (N) resources must be provided for the full RA month.

Core Tariff BPM

RA Application

RR-BRQ034

ITIE, TG, ETIE, resources shall be designated as D resources.

Core Tariff BPM

RA Application

RR-BRQ035

RA application must ensure that the load serving entity provides adequate capacity in RA plan resubmission to cover for prior resource commitments.

Core

RA Application

RR-BRQ036

LSE shall only be able to remove a D resource on the RA Plan if there is an error. Business Rule: D resources can be added on RA Plan resubmission.

Core

RA Application




Technology







RR-BRQ038

RA application must ensure that approved S and N replacements remain on RA Plan resubmittals. S records on the revised plan must at a minimum cover the approved S replacement duration and MW. The system must deduct any approved S MW and S duration from the resubmitted plan, and use this final balance MW and duration for new S replacements. N records on the revised plan must at a minimum cover the approved N replacement MW.The system must deduct any approved S N MW and S N duration from the resubmitted plan, and use this final balance MW and duration for new S and N replacements.

Core

RA Application

RR-BRQ039

Resubmitted plans must include D resources associated with prior approved S replacements.

Core

RA Application

RR-BRQ040

Only incremental S replacements may be submitted after initial publication of the Replacement Requirement.

Core

RA Application

RR-BRQ041

RA application must allow the LSE to resubmit the RA Plan without a resubmission limit prior to T-45.

Core

RA Application

4.4 Business Process: RA Plan Validation Annual – Drop 1

Describes the requirements of the RA Plan validation on an annual level.




RR-BRQ044

RA application must be able to validate date formats for ITIE, TG, ETIES, and TG. Business Rule: These resources can be Subset of Hours (within the month boundaries).

Core

RA Application

RR-BRQ045

RA application must be able to validate administrative tab information.

Core

RA Application

RR-BRQ046

RA application must have the appropriate validation methodology for each given tab.

Core

RA Application




Technology







RR-BRQ047

RA application must allow the Annual Plan to be resubmitted. Business Rule: After the last business day of the Annual Filing Due Date, this shall only be allowed to correct errors and deficiencies.

Core

RA Application

RR-BRQ048

LSEs may submit their Annual RA Plan any number of times up to the Annual Filing Due Date. After the Annual Filing Due Date, LSEs can only resubmit the plan if resubmittal is required.

Core

RA Application




Technology





4.5 Business Process: Supply Plan Upload Validation Monthly – Drop 2

Describes the Supply Plan upload validation on the monthly level.




RR-BRQ052

RA application must ensure that a valid SCID is provided for the duration of the corresponding plan records.

Core

RA Application

RR- BRQ053

System must validate the NQC provided on the Supply Plan per day per resource according to the following formula: The sum of (Resource RA Capacity MW + Outage Group Approved Replacement Capacity MW + Approved S Capacity MW + Approved N Capacity MW + Approved Substitute Capacity MW) must be less than or equal to NQC. Business Rule: This same requirement should apply to resubmittals.

Core

RA Application

RR- BRQ054

System must validate the PMax provided on the Supply Plan per day per resource according to the following formula: The sum of (Resource RA Capacity MW + Outage Group Approved Replacement Capacity MW + Approved S Capacity MW + Approved N Capacity MW + Approved Substitute Capacity MW) must be less than or equal to PMax. Business Rule: This same requirement should apply to resubmittals.

Core

RA Application

RR- BRQ055

RA application must allow suppliers to resubmit the Supply Plan without a resubmission limit prior to T-45.

Core

RA Application

RR- BRQ056

RA application must not allow a supplier to resubmit a Supply Plan at and after T-45.

Core

RA Application

4.6 Business Process: Supply Plan Upload – Annual – Drop 1

Describes the Supply Plan upload validation on the annual level.





Technology







RR-BRQ058

Supplier must have the ability to submit plans any number of times up to the Annual Showings Due Date.

Core

RA Application

RR-BRQ059

After the Annual Showings Due Date deadline, supplier must have the ability to resubmit the plan if resubmittal is required.

Core

RA Application

RR-BRQ060

Upon Supply Plan resubmittal, the RA application must perform the NQC check. ∑(Resource RA Capacity for a day) <= NQC for the day.

Core

RA Application

RR-BRQ061

Upon Supply Plan resubmittal, the RA application must perform the PMax check. ∑(Resource RA Capacity for a day) <= PMax for the day.

Core

RA Application

RR-BRQ062

System must have the ability to validate the import allocation.

Core

RA Application

RR-BRQ063

RA application should have the capability to validate the SCID, MW field, admin tab information, date formats of the LSE. Business Rule: Physical resources must be in monthly increments and can span multiple months.

Core

RA Application

RR-BRQ064

RA application must have the capability to validate date formats for ITIE, TG, and ETIES.

Core

RA Application

4.7 Business Process: Cross Validation of RA and Supply Plans D Resources Only – Monthly – Drop 2

Describes the cross validation of RA and supply plans for D resources.




RR-BRQ066

Cross Validation of the RA Plan to Supply Plan data must occur for a given RA month.

Core

RA Application




Technology







RR-BRQ067

Validation of the cumulative total NQC (compared from both RA and Supply data) must occur per day per resource according to the following formula: The sum of (D Resource RA Capacity MW + Outage Group Approved Replacement Capacity MW + Approved S Capacity MW + Approved N Capacity MW + Approved Substitute Capacity MW) must be less than or equal to NQC.

Core

RA Application

RR-BRQ068

Validation of the cumulative total PMax (compared from both RA and Supply data) must occur per day per resource according to the following formula: The sum of (D Resource RA Capacity MW + Outage Group Approved Replacement Capacity MW + Approved S Capacity MW + Approved N Capacity MW + Approved Substitute Capacity MW) must be less than or equal to PMax.

Core

RA Application

RR-BRQ069

System must have the ability to check whether all resource-contract combinations on the RA Plan appear on the Supply Plan.

Core

RA Application

RR-BRQ070

System should ensure that the total RA Plan resource RA Capacity MW for each LSE does not exceed the total Supply Plan resource RA Capacity MW.

Core

RA Application

RR-BRQ071

Appropriate validation must occur when performing cross validation of the RA and Supply Plans (D resources) – Monthly.

Core

RA Application

4.8 Business Process: Cross Validation Annual Process – Drop 1

Describes the cross validation of the Annual process.




RR-BRQ072

RA application must validate whether the Resource RA capacity is higher on the RA Plan than the Supply Plan. ∑(LSEs RA capacity) > Supply.

Core

RA Application

RR-BRQ073

RA application must validate whether the resource is not on a supply plan but present on RA plans.

Core

RA Application




Technology







RR-BRQ074

RA application must perform a cumulative NQC check. ∑(RA capacity for physical resources) <= NQC If NQC error notify the supplier and the LSE associated with the resource causing the error.

Core

RA Application

RR-BRQ075

RA application must perform a cumulative PMax check. ∑(RA capacity for physical resources) <= PMax If NQC error notify the supplier and the LSE associated with the resource causing the error.

Core

RA Application

RR-BRQ079

LSEs and ISO personnel must have the capability to view the following information:

a. RA application must notify LSE regarding errors resulting from CV run

b. RA application must notify LSE short/long days at TAC and peak without outages.

Core Tariff 40.7.a

RA Application

RR-BRQ080

ISO personnel and Suppliers must have the ability to view the following information: RA application must have the ability to notify the supplier regarding errors resulting from the CV run.

Core Tariff 40.7.a

RA Application




Technology





4.9 Business Process: Outage Impact Analysis (OIA) – Drop 2

Describes requirements associated with outage impact analysis.




RR-BRQ081

RA application must have the capability to determine the effect of selected outages to RA Plan data.

Core

RA Application

RR-BRQ084

System must use only error-free records from the selected input validation result set.

Core

RA Application

RR-BRQ086

RA application must update the T-45 Outage Snapshot with outages canceled and moved since the prior OIA run.

Core

RA Application

RR-BRQ088

RA Application must calculate Resource Availability Due to Outages according to the following process and supporting rules: Step 1

a) SUM THE CAPACITY: Sum RA MW for each resource for all LSEs

b) CAP TO AVAILABILITY: If a resource is on outage and the Resource Availability < RA MW, reduce RA MW to equal Resource Availability received from SLIC

Core

RA Application

RR-BRQ088 (cont.)

Step 2 – Part 1) a) PRO-RATE: If the resource is shared by

multiple LSEs, pro-rate the (reduced) RA MW across all LSEs sharing the resource. Result is the Outage Obligation per LSE

Core

RA Application




Technology





4.10 Business Process: CAISO System Reliability Margin (CSRM) Check – Drop 2

Describes requirements associated with the system reliability margin check.




RR-BRQ090

System must have the capability to perform the CAISO System Reliability Margin Check (CSRM).

Core

RA Application

RR-BRQ092

RA application shall use the following as inputs into CSRM:

1. Outage Impact Analysis Results 2. Supplier approved “S” replacements 3. Supplier approved “N” replacements 4. CAISO System RA Reliability Margin

Adjusted CEC peak demand requirement

5. OM Approved Replacement Capacity for outages received T-45 to T+31

Core

RA Application

RR-BRQ094

RA Application must be able to validate the CSRM at the System level and LSE level.

Core

RA Application

RR-BRQ098

System shall use the following as input to the TAC validation:

RA and Supply Plan Validation (LSE RA Data)

Outage Impact Analysis

Supplier approved “S” replacements

Supplier approved “N” replacements

LCR requirements (TAC and individual LSE level)

Outage Management approved replacement capacity received T-45 to T+31

Core

RA Application

RR-BRQ099

RA Application must be able to perform validation at the LSE and TAC level.

Core

RA Application

4.11 Business Process: Specified (S) Replacements – Drop 2

Describes requirements associated with the specified (S) replacements.





Technology







RR-BRQ101

System must have the following as input to the S replacement process:

Selected Outage Impact Analysis

Approved “S” replacement data (approved by supplier)

Rank for S resources from RA Plan associated with the OIA module result set (unused S resources and/or their balance left over MW)

Core

RA Application




Technology







RR-BRQ102

System must use the following process to replace S resources:

1. If RA for a D resource per LSE per day is impacted due to a planned outage and the resource has an approved “S” replacement then the duration and MW of the approved S replacement is locked out and must not be double counted for another replacement. (Approved replacements remain approved for the RA life cycle)

a. If additional S capacity is now available for the same resource/duration, then use the balance available S capacity for the same resource

b. If additional S capacity is now available for another resource/duration, then use the balance available S capacity for the other resource

2. If RA for a D resource is impacted due to outages then check if S replacement is available for the D resource

3. If S replacement available for the period of the outage impact then use the S resource a. Use S resource for any duration of the outage impact if available

4. The S MWs used for the replacement shall not exceed the original RA on the D resource (RA on D before impact of planned outage) and the S MW must only cover the outage impact (nothing more) a. Replacement duration/MW shall not go beyond the outage impact duration/MW

5. If D resource is listed multiple times on a RA plan with different contracts then prorate the S replacement across the D’s contracts

6. If the LSE provided multiple S resources to cover a D resource on an outage and the total S capacity is more than the outage impact then prorate the usage of these S resources to meet the outage impact

Core

RA Application




Technology







RR-BRQ103

System must perform a NQC check after using the S capacity. The NQC check should be based on the following:

a) ∑( D Resource RA capacity + outage approved capacity + approved S capacity + approved N capacity + approved substitute capacity + Pending S capacity ) <= NQC

b) If total exceeds NQC then flag it and cap the MWs at the NQC value and prorate across the usage maintaining higher priority for D and approved capacity followed by pending S

Core

RA Application

RR-BRQ105

System must perform a PMAX check after using the S capacity

a. ∑( D Resource RA capacity + outage approved capacity + approved S capacity + approved N capacity + approved substitute capacity + pending S capacity ) <= PMAX

b. If total exceeds PMAX then flag it and cap the MWs at the PMAX value and prorate across the usage maintaining higher priority for D and approved capacity followed by pending S.

Core

RA Application




Technology





4.12 Business Process: Non-Specified (N) Replacements – Drop 2

Describes requirements associated with the non-specified (N) replacements.




RR-BRQ108

RA Application must use the following as input to the N Replacement process:

a) Valid OIA results which include Outage Data b) CAISO System RA Reliability Margin process

output a. System Level b. Individual LSE Level

Core

RA Application

RR-BRQ109

System must use the following process to perform N Replacement for each cumulative system short day:

i. For each outage impacting this day in Last in First Out (LIFO) order 1. Stack the total system D RA available

MW, then on top of the stack, lay the outages in reverse order (outage with the latest priority timestamp is put on top of the RA stack first, work the way up until the outage with the earliest priority timestamp is placed on top of the stack)

2. While laying the outages in reverse order, stack up only the IMPACT MW and not the whole outage derate.

3. Use the outage impact MWs which is causing system shortage (Identify the latest outage contributing to system shortage)

4. Determine which LSEs share this resource that is on outage

5. Determine the ratio in which each LSE shares this resource (This was an input)

Determine the MW amount each LSE is responsible for based on above items (outage obligation) –: Prorate the outage Impact MW across LSE contracts, based on the D resource’s RA MWs per contract.

Core

RA Application




Technology







RR-BRQ110

The following rules must be taken into account for each of these LSEs that are on the Outage, in the order of the highest LSE outage obligation

1. if the LSE has not met its individual obligation (peak demand and reserve margin) for this day and if it is an approved planned outage and if the

LSE provided N replacement capacity which covers this day then use N replacement capacity in rank order up to its outage obligation limited by

a. Assigned N capacity which has not been rejected by the supplier (do not use approved N capacity)

b. its individual peak demand and reserve margin

c. NQC check after using the N capacity– i. ∑( D Resource RA capacity +

outage approved capacity + approved S capacity + approved N capacity + approved substitute capacity + Pending N capacity ) <= NQC (ignore any pending S)

ii. If total exceeds NQC then flag as invalid.

d. PMAX check after using the N capacity– ∑( D Resource RA capacity + outage approved capacity + approved S capacity + approved N capacity + approved substitute capacity + Pending N capacity ) <= PMAX (ignore any pending S)

i. If total exceeds PMAX then flag as invalid.

e. If the outage is in pending state then add the outage impact MWs to the replacement requirement

i. Keep track of unused N capacity (MW and duration), so that it can be reused against another outage if required.

ii. If after exhausting all N capacity for this LSE and the LSE is still short on this outage obligation then the remaining shortage is added to its Replacement Requirement MW for the duration.

Replacement Requirement must be tracked per LSE per MW per outage (resource) per day basis.

Core

RA Application




Technology







RR-BRQ111

System must perform the following logic: 1. If the cumulative system + assigned N

replacements + assigned Replacement Requirement meets the CAISO System Reliability Margin then the cumulative system requirement was met for the day, so move on to the next day.

2. Approved replacements remain approved for the RA life cycle

a. This result set should only include new replacements

Core

RA Application

4.13 Business Process: Management of S and N Replacements – Drop 2

Describes requirements associated with the management of S and N replacements.




RR-BRQ114

System must allow ISO personnel to select and publish S replacement result sets to suppliers for approval. Business Rule: The publish process must be at the S module run level.

Core

RA Application

RR-BRQ116

RA Application shall display the published S Replacement result sets to authorized users (SCs) for approval. The published result set for approval must display the following fields:

S replacement run details – run Id, Submittal type, Trade Month, Trade Year

S Replacement Start Date

S Replacement End Date

S Replacement Resource

S Replacement MW

S Replacement Status (Group by Pending, Approved, Rejected)

Supplier

LSE

Approve/Reject button

Core

RA Application

RR-BRQ117

System must display pending S replacements from the latest published S run.

Core

RA Application




Technology







RR-BRQ118

System must allow SC users to approve or reject pending S replacements.

Core

RA Application

RR-BRQ119

System must allow authorized Suppliers to approve or reject single/multiple replacements.

Core

RA Application

RR-BRQ121

RA Application shall automatically reject pending S replacements if the supplier has not responded by the end of the day, two business days after the replacement run. Example: If the S module run occurs on Monday, then after business hours on Wednesday the system must set the status of pending S replacements from this run to ‘Rejected’

Core

RA Application

RR-BRQ122

RA Application shall automatically reject pending S replacements at 23:59:59 T-13. Business Rule: This will ensure that at the onset of T-12, all S replacements will be in either approved or rejected status.

Core

RA Application

RR-BRQ124

RA Application must validate NQC upon approval and reject invalid approvals per the following logic: ∑(D Resource RA capacity from the RA plans used for the S module run + outage approved capacity + approved S capacity + approved N capacity + approved substitute capacity ) <= NQC

Core

RA Application

RR-BRQ125

RA Application must validate PMAX upon approval and reject invalid approvals per the following logic: ∑(D Resource RA capacity from the RA plans used for the S module run + outage approved capacity + approved S capacity + approved N capacity + approved substitute capacity ) <= PMAX

Core

RA Application

RR-BRQ127

RA Application must display Pending N replacements from the latest published N run. Upon publish of a run, pending and rejected N replacements from prior published N runs for the same period and submittal type must no longer be visible to users.

Core

RA Application

RR-BRQ128

SC users must have the ability to approve or reject pending N replacements.

Core

RA Application

RR-BRQ129

System must allow Suppliers the ability to approve or reject single/multiple N replacements.

Core

RA Application

RR-BRQ130

RA Application shall automatically reject pending N replacements if the supplier has not responded by the end of the day, two business days from replacement run. Example: If the N module run occurs on Monday, then after business hours on Wednesday the system must set the status of pending N replacements from this run to ‘Rejected’

Core

RA Application




Technology







RR-BRQ131

RA Application shall automatically reject pending N replacements at 23:59:59 T-13 This will ensure that at the onset of T-12, all N replacements will be in either approved or rejected status.

Core

RA Application

RR-BRQ133

RA Application must validate NQC/PMAX upon approval and reject invalid approvals per the following:

∑(D Resource RA capacity from the RA plans used for the N module run + outage approved capacity + approved S capacity + approved N capacity + approved substitute capacity ) <= NQC/PMAX

Core

RA Application

4.14 Business Process: LSE View of Replacement Data and Errors – Drop 2

Describes requirements associated with the LSE view of replacement data and errors.




RR-BRQ136

LSEs must have to capability to view all accepted, rejected (supplier rejected or ISO rejected or system automated rejected after 2 business days), pending S and N replacements used by ISO.

Core

RA Application

RR-BRQ137

LSE users must have the ability to view their replacement requirement MW per day.

Core

RA Application

RR-BRQ138

RA Application must allow authorized LSE users to resubmit their RA Plan with a cure if the LSE is short and has a replacement requirement If the LSE does not have a replacement-requirement-MW > 0 for any day within the Target Month, then resubmittal must not be allowed.

Core

RA Application

RR-BRQ139

RA Application must notify LSE for the short/ long days at TAC and peak with outages, without outages, with outages + replacements (S and N).

Core

RA Application

RR-BRQ140

RA Application must have the ability to notify the LSE regarding errors resulting from the CV run.

Core Tariff 40.7.a

RA Application




Technology





4.15 Business Process: Supplier View of Replacement Data and Errors – Drop 2

Describes requirements associated with the supplier view of the replacement data.




RR-BRQ142

RA Application must allow ISO personnel to publish notifications to Supplier users on demand.

Core

RA Application

RR-BRQ143

RA application must have the ability to notify suppliers regarding errors resulting from the CV run.

Core Tariff 40.7.a

RA Application

4.16 Business Process: RA related requirements

Describes requirements associated with RA.




RR-BRQ157

System must send daily RA data to SLIC and RAAM beginning at the Showing Due Date (typically T-45) for a RA month.

Core

RA Application; SLIC; RAAM

RR-BRQ158

Resources that are used as D, approved S and/or approved N shall add the MWs on the associated days and hours to give date-range records that span days/hours where the RA capacity is the same.

Core

RA Application

RR-BRQ145

The RA Application must perform a final NQC check per resource per hour 1. Total capacity = ∑ (RA capacity (D) from the selected CV module output + approved S capacity+ approved N capacity + approved substitute capacity + approved outage replacement capacity) < = NQC 2. If error do not promote. Report resource and designations causing the error 3. Do not promote data for any resources for any day

Core

RA Application




Technology







RR-BRQ146

The RA Application must perform a final PMAX check per resource per day

1. Total capacity = ∑ (RA capacity (D) from the selected CV module output +approved S capacity+ approved N capacity + approved substitute capacity + approved outage replacement capacity) < = PMAX

2. If error do not promote. Report resource and designations causing the error

3. Do not promote data for any resources for any day

Core

RA Application

RR-BRQ147

RA Application must have the ability to send daily RA data to the appropriate systems at T-7 for a RA month.

Core

RA Application

RR-BRQ181

All users must be prohibited from performing any “write-transactions” while any background module is running. Business Rule: Users need to have the ability to perform view functions within the application.

Core

RA Application

RR-BRQ182

Background modules must be scheduled to run at 4 AM and 6 PM Pacific Prevailing Time (PPT) daily from the T-45 to T-11 window for a given compliance month.

Core

RA Application

RR-BRQ183

System must provide the capability for LSE users to view the LSE level obligation by day and their position with respect to the obligation MW. Business Rule: LSE users must only be able to view their own data.

Core

RA Application




Technology





4.17 Business Process: Outage Management (OM) from T-45 to T+31 – Drop 2

Describes requirements associated with outage management.




RR-BRQ148

Outage system must use the appropriate data

sources to capture data within the T-45 to T+31

timeframe.

Core

SLIC

RR-BRQ150

RA Application must grant authorized Supplier the

ability to request outage replacement between T-44 to

T+31.

Core

RA Application

RR-BRQ151

System must allow multiple resources to replace

single/multiple outage.

Core

RA Application

RR-BRQ152

System must have the ability to allow one resource to

replace many resources.

Core

RA Application

RR-BRQ153

The RA Application must show the available RA vs. available Non-RA.

Core

RA Application

RR-BRQ154

Replacement capacity shall be used to cover the impact of planned outage in a manner outlined below:

1. Replacement capacity to be subjected to all bidding obligations (40.6) and standard capacity product provisions (40.9).

2. Replacement capacity exempt from G204 rules

a. Replacements units should be internal to CAISO BAA and ITIE, TG, ETIES cannot be used as replacements (Res_Type of ITIE, TG, ETIE, TG, ETIE cannot be used as replacement units)

b. Remove area check (local for local, system only)

c. Remove dispatch-ability check d. Remove ramp rate check

3. Replacements can be many to many a. One resource can replace many

outages b. Many resources can be used to

replace a single outage 4. Time frame for Replacements – T-44 to T+31 5. Replacement resources must have NQC

Core Tariff 40.6; 40.9

RA Application




Technology







RR-BRQ154 cont.

i. Outage group to approve replacements ii. Settlements to get availability data for all

resources including replacements. iii. Non RA = NQC – (RA capacity in

production or staging table depending on the time frame of the request + OM approved replacement capacity + approved S/N replacement capacity + approved substitute capacity)

iv. Replacement capacity should be operationally available for the replacement capacity

a. The replacement unit’s replacement capacity must be available (based on Availability from SLIC)

b. i.e. SLIC Availability of replacement unit >= non-RA of the replacement unit

a. Replacements are only for planned outages (system to validate Outage Id to ensure it is planned)

b. The tool should allow suppliers to submit replacement requests only for new outages after T-45 to T+31.

Note: Outages before T-45 (snapshot) is handled by LSEs by resubmitting the RA Plan

Replacements must appear in RAAM to allow SCs to perform Substitutions on the Replaced Resource.

Core

RA Application

RR-BRQ155

System must show the resource level information of the original and replacement resource. Business Rule: Fields should be similar to the Substitution screens in RAAM.

Core SLIC

RR-BRQ159

Replacement requests for Third Party Replacements must trigger notification to the third party.

Core SLIC

RR-BRQ160

Third Party replacements need to be approved by the third party before Outage Management approves the Replacement.

Core SLIC

RR-BRQ162

RA Application must validate NQC upon approval of a replacement request. Resource RA in production or Stage based on timeframe + approved S + approved N + outage approved replacement capacity + approved substitutions <= NQC

Core RA Application




Technology







RR-BRQ163

RA Application must validate PMax upon approval of a replacement request. Resource RA in production or Stage based on timeframe + approved S + approved N + outage approved replacement capacity + approved substitutions <= PMax

Core RA Application

RR-BRQ164

RA Application must prevent ITIE, TG, ETIES from being selected as replacement resources on the replacement request.

Core RA Application

RR-BRQ165

RA Application must allow only resources internal to the ISO Balancing Authority Area to be selected as replacement resources on the replacement request.

Core RA Application

RR-BRQ166

Replacements must not cross the month boundary. Core RA Application

RR-BRQ167

Replacements must be at a minimum for a full day. Replacements can be in daily increments (no subset of hours).

Core RA Application

RR-BRQ168

Only available non-RA capacity shall be used for replacements. This available non-RA capacity must not have a CPM designation.

Core RA Application

RR-BRQ169

Outage approved replacements must only be allowed against Planned Outages.

Core RA Application

4.18 Business Process: Scheduling Coordinator Transfers – Drop 2

Describes requirements associated Scheduling Coordinator transfers.




RR-BRQ170

RA Application must use the appropriate data sources in the Scheduling Coordinator transfer process.

Core RA Application

RR-BRQ171

RA Application must validate the association between

resource and supplier each time a Supply Plan is

uploaded.

If the association is invalid for the compliance month,

RA Application must reject the upload

RA Application can assume that the effective date of

the SC association will always cover an entire

compliance month.

Core RA Application




Technology







RR-BRQ172

System must have the ability to validate the

association between resource and supplier for each

Supply Plan on a daily basis.

Business Rule: This daily process must run from T-45

through T-7 only, and must look to see if SC

associations change for the compliance month T.

Core RA Application

RR-BRQ173

System must remove a transferred resource from the

previous SC’s Supply Plan when a resource-supplier

association has been changed.

Core RA Application

RR-BRQ174

System must insert a transferred resource into the

Supply Plan for the new SC when a resource-supplier

association has changed.

Core RA Application

RR-BRQ175

System must create a new Supply Plan when a

resource-supplier association has changed and the

new SC does not have a Supply Plan for the

compliance month.

Core RA Application

RR-BRQ176

System must display to the old SC that their Supply

Plan has been changed due to a resource transfer (for

D resources) or that they have approved / pending

S/N resources that got transferred away.

Core RA Application

RR-BRQ177

RA Application must display to the new SC that their

Supply Plan has been changed or created due to a

resource transfer (for D resources) or that they have

approved / pending S/N resources that got transferred

in.

Core RA Application

4.19 Business Process: Multi-Stage Generating (MSG) Requirements

Describes requirements associated with MSG.







Technology







RR-BRQ187

A mechanism must be provided to allow Market

Participants to submit an explicit MSG configuration

for every potential RA value from PMin to PMax of the

resource.

Business Rules:

The RA values must be contiguous. The RA min of

the second configuration must = the RA max of the

previous configuration plus .01 to avoid “real number”

gaps. (Note: configurations have no defined order.

“Second” and “previous” are relative to the RA range,

not the configuration pmin or pmax.)

RA range Max must be equal to or less than the PMax

for that configuration.

RA range Min must be greater than or equal to the

PMin for that configuration unless there is no valid

MSG configuration for that RA range, then the

configuration identified must be the one with the

lowest Pmin greater than the RA range Min value

whose Pmax is greater than RA range Max.

Core Master File

RR-BRQ208

Remove RA Capacity and RA Flag fields from

Generator Resource Data Template (GRDT) and

Inter-tie Resource Data Template (IRDT) per project

schedule. Master File changes must be deployed

with major release (next RDT change).

Core Master File

RR-BRQ209

“Default RA Path Sequence” will be removed from

the GRDT but will remain in the Transition MV to

display historical values. If MP wants to know

historical value(s), they will need to request the

information from the Model & Contract Implementation

(MCI) team.

Core Master File

RR-BRQ188

Master File must send the configuration RA range data to SIBR.

Core Master File; SIBR

RR-BRQ190

SIBR’s query must select the MSG configuration that is based on the RA value from the default RA configuration table.

Core Master File; SIBR

RR-BRQ207

SIBR will fill in the default energy bid for that default

configuration and all configurations underneath the

default configuration to be bid if their bid does not

meet the RA requirement.

Core SIBR

RR-BRQ192

Market Systems must determine the optimal

startup/transition path for the selected configuration.

Core SIBR




Technology





4.20 Business Process: Resource Adequacy Availability (RAAM) – Drop 2

Describes requirements associated with RAAM application.




RR-BRQ193

System must not receive pre-promoted data from RA Application prior to the T-7 window.

Core RAAM; RA Application

RR-BRQ194

System must receive final RA data from the RA Application from T-7 through T+31.


RR-BRQ195

System must receive Outage Scheduling data from T-7.

Core SLIC; RAAM

RR-BRQ196

RAAM must not allow SCs to submit replacements for planned outages.

Core RAAM

RR-BRQ197

System must display final RA value for RA/Non-RA (MW) (at daily granularity) – resource level.

Core RAAM

RR-BRQ198

Substitution performed within RAAM must be available to downstream systems.


RR-BRQ199

System must validate Outage IDs entered in the screens/APIs to ensure they are valid for Forced Outages per Outage System.

Core RAAM; SLIC

RR-BRQ200

Substitutions must not cross month boundaries and must not be allowed for dates on which the unit is not RA.

Core RAAM

RR-BRQ201

Substitutions MW must be limited to the minimum RA Capacity within the date range of substitution.

Core RAAM

RR-BRQ202

System must enforce the following rules for substitution capacity –

Unit substitutions are for forced outages, the substitute capacity does not become a Resource Adequacy resource

Time frame for substitutions – T-7 (subject to RA data being available in the final promoted state) to T+31.

Substitutions should follow G204 rules

Substitutions are only one to one and one to many. Many to many not allowed (due to settlements impact). No change to current implementation

Substitution logic to work only on final promoted RA data

Core RAAM




Technology







RR-BRQ203

System must enforce the following rules for substitution capacity:

Substitutions can be prequalified

Settlements to get availability data for all resources including substitutions– no change

Settlements require the linkage between the original resource and substitute resource – no change

Non RA = NQC – (RA capacity in production + OM approved replacement capacity + approved substitute capacity) - change

Validate the Outage ID to ensure it is a Forced Outage

The Ramp rate of the substitute unit should be equal or greater than the original unit. If check fails then flag error on submit – Invalid substitution

Core RAAM

4.21 Business Process: Settlements – Drop 2

Describes requirements associated with Settlements.




RR-BRQ205

Settlements must be able to receive RA replacement designation by unit from RA Application.

Core Settlement System; RA Application

RR-BRQ206

Short Notice Opportunity Outages that are forced outages must not result in Standard Capacity Product (SCP) penalties.

Core RA Application




Technology





Appendix A: Terms and Definitions

The following terms are used within this document. Where applicable, the terms are sourced from the current Business Practice Manual for Definitions & Acronyms.

Term Acronym Definition Potential Tariff or

BPM Term?

ISO

Reliability

Requirements

IRR This application validates, maintains, and reports on Resource

Adequacy information.

Existing

Term

Master File MF

This application maintains reference data for Market

Participants, Resources, Contracts, etc. for use by Market

Participants and downstream applications.

Existing

Term

Non-

specifiedRA

Capacity used to substitute for a RA resource with scheduled

planned outages that requires replacement of RA capacity. Potential

Resource

Adequacy

Availability

Management

RAAM Software application used to request unit substitution for RA Resources.

Existing

Term

Resource

Adequacy

Compliance

Year

The calendar year in which RA activities are conducted. Existing

Term

Resource

Adequacy

Plan

A submission by a Scheduling Coordinator for a Load Serving

Entity in order to satisfy the requirements of Section 40 of the

ISO Tariff.

Existing

Term

Scheduling

Logging for

ISO of

California

SLIC Schedule and Logging system for the CAISO. Existing

Term

Supply Plan

A submission by a Scheduling Coordinator for a Resource

Adequacy Resource in order to satisfy the requirements of

Section 40 of the ISO Tariff.

Existing

Term




Technology





Appendix B: Timeline

T-45 T+31T-25 T-10 T-7 T-0-Monthly RA Plan -Monthly Supply Plan

All O

utages

(for R

A

Co

mp

liance

Mo

nth

) cured

b

y RA

Sup

plier

Tasks Performed (Based on outages received by T-45):- Cross validation of RA Plans and Supply Plan.- Check for planned outages of RA resources to assure reliable RA levels are maintained.- Identify RA capacity that needs to be replaced.

Assu

med

that

LSE RA

plan

s d

o n

ot

con

tain

resou

rces with

u

n-rep

laced

ou

tages.

- Provide the Local Regulatory Authority (LRA) with inconsistencies between RA plans and supply plans.- Inform RA suppliers and LSE of which outages require replacement.- Track automatic replacement of Non-Specified RA.- A RA supplier can give notice to the ISO that the generator is withdrawing the outage request.- ISO shall notify LSE of potential RA backstop capacity procurement.

Replacement Requirement for Scheduled Generation Outages Timeline

- Optional Final RA plans due (all inconsistencies cleared).- ISO may procure RA backstop capacity for the LSE that is short capacity.- Last day for the LSE to provide replacement capacity.

- Load supply plans.

Supplier can request Short-term opportunity outages




Technology





Appendix C: Business Process Steps

Business Process: LSE submits RA plan (includes specified replacement and non-specified). System Change: (Automated) Additional columns for RA Plan Designated Flag (D – designated, NS- Non Specified, S- Specified). Unit to be replaced (for specified units, which unit is it replacing). Specified units could appear multiple times in a RA Plan (overlapping dates are allowed); dates do not have to be start/end of month. A specified unit can have multiple records with overlapping days such that the sum of the rows for any day exceeds NQC MW.

Business Process: Upload validation (against RA obligation) – check for errors- if no errors, LSEs are locked out – ignores outages. System Change: (Automated) Upon validation, if all checks pass, then version the RA plan for the LSE for the Trade Month and insert the data from the new plan. Similarly, for the Supply Plan resubmission, version the existing plan data.

Business Process: Cross validation against supply plans – against only designated RA without considering outages (monthly). System Change: (Automated) Only consider Designated resources and run existing rules on this subset of data.

Business Process: Send report to CPUC only for RA resources (about discrepancies between LSE plan and RA obligation or Supply plan). System Change: (Automated) IRR produces the output in the Cross Validation (CV) status screen. (Monthly)

Business Process: Apply active (not canceled or returned to service) SLIC outages (submitted as of T-45) to all resources in the RA plans (for each day). System Change: (Automated) SLIC to provide list of outages (database to database short term, web service long term). IRR to consume this data and break up the RA and Supply records (RR_SP_Resources, and RR_SH_Resources) to reflect the available RA capacity by day. Sum up the RA capacity across RA plans for each resource. If the SUM(RA Plan MW)>Supply plan MW, prorate the Required Replacement MW based on the RA Plan MW to each LSE.




Technology





Business Process: Outage Management must know if a non-specified resource is on outage and is going to be used for replacement. System Change: (Automated) Report that tracks “only” the changes in status D, S, and N within and across submissions. Notes: Changes to RAAM for the daily granularity issues. Approved Substitutions take precedence of “S” and “N” RA conversion to “D”.

Business Process: ISO to replace (fill in outages) with “specified” units in LSE RA Plan. System Change: (Automated) Automatically apply the day-level replacements into RR_SH_Resources and RR_SP_Resources. SH information is applied directly; whereas, the Supply plan needs approval.

Business Process: Verify that all new “specified” units are available from the supplier for the days and capacity that is needed. System Change: (Automated) Phone call (need logging mechanism to track this with supplier) to supplier. Approve the replacement records in the tables.

Business Process: Notify LSEs/Supplier that specified resource replacements have been made. System Change: (Automated) Build new screen to display records being considered for RA capacity for the LSE.

Resource ID

Start Date

End Date

MW

Flag to indicate whether it was part of the original RA Plan/Supply Plan

Business Process: Get supplier confirmation that “specified” resources are now RA and available. System Change (same system change as documented in RR-FRQ145: (Automated) Phone call to supplier. Approve the records in the temp tables:

Move these records into the main tables

Break up the RR_SH_Resources and RR_SP_Resource records for the original unit to remove those days where the replacement has occurred.




Technology





Business Process: Conduct cumulative system and local test – for each day. If test passes, no replacement is necessary. System Change: (Automated) Modify IRR to run daily level cross validation. Cross validation is to ensure that the resource does not exceed its NQC (all resources). Cross validation must be performed at the daily level for physical resources. For intertie resources, take the max RA capacity for any hour within the day. During this check the system must do the cumulative system validation:

Considers the outages, hence all the designated resources as of right now (includes those that were replaced in)

Must produce a new report showing the status

If below system 115%, then there must be a listing of LSEs that fail the individual RA obligation check

For those LSEs failing the individual RA obligation check, display their outages in LIFO.

Business Process: If Cumulative system test fails (is <115%), determine which individual LSE plans need replacement based on individual obligation (including planned outages from SLIC for each day). System Change: (Automated) To determine who needs replacements, LSEs that are short (below their RA obligation) on the day of Cumulative system test failure that used resources that have a planned outage for the day.

Business Process: ISO to replace (fill in outages) with non-specified units per priority in LSE RA plan. Rules (for outage replacement):

Outage replacement will be considered in the order of “last in – first replaced)

Must replace outages (by days) that will allow the cumulative system test to pass

ISO shall assume un-replaced outages will be replaced during the cure period

Business Rule: The ISO shall assume the outage that has no non-specified replacement will be resolved via cure period as opposed to over resolving prior to the cure period. System Change: (Manual) Provide screen/direct database access for business to input the day-level replacements into RR_SH_Resources_Temp (temporary table). Provide screen/direct database access for business to input the day-level replacements into RR_SP_Resources_Temp (temporary table).




Technology





Business Process: Verify that all new RA resources are available from the supplier for the days and capacity that is needed. System Change: (Automated) Phone call to supplier. Approve records in the temp tables:


Break up the RR_SH_Resources and RR_SP_Resource records for the original unit to remove those days where the replacement has occurred..

Business Process: Notify LSEs/Supplier that non-specified resource replacements have been made (first report out prior to T-25 and continues to T-10) and any deficiencies. System Change: (Automated) Build new screen to display records being considered for RA capacity for the LSE.

Resource ID

Start Date

End Date

MW

Flag to indicate whether it was part of the original RA Plan/Supply Plan

Business Process: Get supplier confirmation that resource is now RA and available. System Change (same system change as documented in RR-FRQ145: (Automated) Phone call to supplier. Approve the records in the temp tables:


Break up the RR_SH_Resources and RR_SP_Resource records for the original unit to remove those days where the replacement has occurred.

Business Process: Specified and non-specified resources that have been confirmed now become new RA resources for the period and amount of capacity is needed. (If LSE’s plan is fine with replacements, take no further action). If LSE plan is still short, continue to RR-FRQ153.

Business Process: LSE submit cured outage/replacement plan ISO tab (only new replacements or cancellation of outages) no later than T-10. Have to validate again from cross validation against supply plans (against only the designated RA without considering outages –monthly). System Change: (Automated) Wipe out plan data for resubmitted RA/Supply Plans. Store the prior plan data to history tables.




Technology





Business Process: Send final CPUC report (T-7) (updated with outages and with replacements). System Change: (Automated) IRR produces the output in the CV status screen. Business has been provided a query to extract the data from the database. If we need to send the outage and replacement data, this query will need to be updated.

Business Process: Any outages in need of replacement not cured by the LSE would be backstopped by the ISO.