Business Requirements Specification Requirements Specification ... as the initial set of business unit requirements for the appropriate software ... phase will address and enhance

Owner: Thaker, Tarak Program Office

ISO Public

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

Business Requirements Specification

Enabling Demand Response – Registration Enhancements

Document Version: 1.0

Date Created: 5/8/2015

Disclaimer


ISO Public


Technology

Template Version: 3.1


Enabling Demand Response – Registration Enhancements Business

Requirements Specification - Planning Date Created: 5/8/2015

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.


ISO Public


Technology





Table of Contents

TARAK THAKER INTRODUCTION ................................................................................................................................................ 3

1.1 PURPOSE .................................................................................................................................................................................... 4

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

2.1 DESCRIPTION.............................................................................................................................................................................. 5

3. BUSINESS PROCESS IMPACTS .............................................................................................................................................. 6

3.1 HIGH LEVEL BUSINESS PROCESS ............................................................................................................................................... 6

3.1.1 Description ...................................................................................................................................................................... 6

3.1.2 Pros .................................................................................................................................................................................. 6

3.1.3 Cons ................................................................................................................................................................................. 6

3.2 RISKS AND MITIGATION ............................................................................................................................................................. 6

3.3 JUSTIFICATION ........................................................................................................................................................................... 6

4. BUSINESS REQUIREMENTS ................................................................................................................................................... 7

4.1 BUSINESS PROCESS: MANAGE LOCATIONS ................................................................................................................................ 7

4.1.1 Business Requirements .................................................................................................................................................... 7

4.2 BUSINESS PROCESS: MANAGE REGISTRATIONS ....................................................................................................................... 17

4.2.1 Business Requirements .................................................................................................................................................. 17

4.3 BUSINESS PROCESS: MANAGE RESOURCES .............................................................................................................................. 24

4.3.1 Business Requirements .................................................................................................................................................. 24

Tarak Thaker


ISO Public


Technology





Introduction

1.1 Purpose

The purpose of this document is to capture and record a description of what the Users and Business Stakeholders of the project wish to obtain by providing high-level business requirements. This document establishes the basis for the agreement between the initiators and implementers of the project. The information in this document serves as input to determining the scope of Information Systems projects and to all Business Process Modeling and System Requirements Specifications efforts.

These requirements will serve as the initial set of business unit requirements for the appropriate software application/systems development effort. It is understood that additional requirements and systems analysis may produce “To Be” Business Process Models, System Requirements Specifications, and Use Cases to serve as the set of requirements documents used by the 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 requirements documentation produced.


ISO Public


Technology





2. Details of Business Need/Problem

2.1 Description

Previous Phases:

The Enabling Demand Response project’s API (Phase 1) functionality went live in April 2015. The APIs allow for a more streamlined and automated Proxy Demand Response (PDR) and Reliability Demand Response Resources (RDRR) location registration process. This functionality should have alleviated a major technical hurdle, allowing for fuller demand response participation in CAISO’s markets and reliability functions.

Current Project:

The Enabling Demand Response Registration Enhancements (Phase 2, detailed in this BRS aims to transfer the PDR/RDRR registration model and functionality from the Demand Response System (DRS) into the California ISO’s Demand Response Registration System (DRRS). The registration model and process will be streamlined based on input from a customer outreach. PDR and RDRR resource rules and associated functionality will be implemented in the DRRS. The DR entity model (including entities such as locations, registrations, resources data) will be updated for a more efficient and automated process flow while accelerating timelines as requested by stakeholders. The entity model update includes the removal of the aggregate location (ALOC) concept. A future phase will address and enhance meter data submittal and retrieval, baseline calculations, and settlements functionality. This future phase will rely on entity modeling addressed in Phase 2 (this BRS).


ISO Public


Technology





3. Business Process Impacts

3.1 High Level Business Process

3.1.1 Description

Registration Methodology - DRRS 1. Implementation of base registration functionality including:

a. PDR rules and functionality b. RDRR rules and functionality

2. Effective dating synergy across locations, and registrations for participation continuity 3. Registration management via robust APIs in addition to a robust user interface 4. Allow for a one-to-many mapping between resources and registrations 5. Resource ID business rules for exclusivity between PDR and RDRR Resource IDs

3.1.2 Pros

The DR resource registration update will align the stakeholder’s business process for better usability. The Resource registration functionality will shift from the DRS system to the California ISO DRRS system resulting in a significant cost savings in terms of licensing, future requirement updates, and maintenance.

3.1.3 Cons

No cons have been identified.

3.2 Risks and Mitigation

No risks have been identified.

3.3 Justification

As the California ISO strives for greater demand response penetration, these requirements are essential to expanding the DR portfolio in a usable manner.


ISO Public


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: Manage Locations

4.1.1 Business Requirements

ID# Business Feature

Requirement Type

Business Unit(s) Affected

Potential Application(s)

Impacted

REGE-BRQ100

The system shall provide interfaces (both API and UI) to allow the DRP to create, modify, and remove locations; to allow LSE and UDC to review locations.

Note: Existing Functionality

Core

MSMEA DRRS


ISO Public


Technology






Requirement Type



Impacted

REGE-BRQ102

The system shall provide a user interface (and API) allowing the DRP the ability to provide the following location information:

DRP ID (unique)

UDC ID (unique)

LSE ID (unique)

SubLAP (unique)

Location Name

Effective Start Date

Effective End Date

Service Account Number (SAN) (unique per UDC )

Pnode (optional if being used as part of pre-defined DR resource, and mandatory if planned for use in custom resource)

Load Reduction Curtailment Value (LRCV) in kW

Address

o Street Address

o City

o State

o Zipcode

Note: All location data fields are mandatory. Except for Pnode.

Core

MSMEA DRRS

REGE-BRQ104

The system shall not be collecting the location profile information. There is no longer a need for breakdown of the location LRCV into sub components.

Core

MSMEA DRRS

REGE-BRQ106

The system shall perform the following UI data validations upon location creation:

Valid DRP ID, UDC ID, LSE ID, SubLAP, and Pnodes shall be made available for selection based on Master File data (drop down list, no free form text)

Core

MSMEA, MCI

MF, DRRS


ISO Public


Technology






Requirement Type



Impacted

REGE-BRQ108

When submitting location data via an API, the system shall ensure that the following data elements are valid against the Master File:

DRP ID, UDC ID, LSE ID, SubLAP, and Pnodes

Core

MSMEA, MCI

DRRS

REGE-BRQ110

The system shall enforce a unique identifier for locations to prevent duplicate or overlapping locations.

Core

MSMEA DRRS

REGE-BRQ112

Location Name can contain alphanumeric and special characters, upto a maximum of 255 characters.

Core

MSMEA DRRS

REGE-BRQ114

SAN can contain alphanumeric and special characters, upto a maximum of 255 characters.

Core

MSMEA DRRS

REGE-BRQ116

Business Rule: A SAN must be unique for a given location within the same UDC for a given effective date range.

If two locations have the same SAN but have two different UDCs, the system shall accept them as not being duplicates.

Core

MSMEA DRRS

REGE-BRQ118

If a duplicate SAN is entered, the system shall reject the submission with an error message providing details of the already existing location that includes but not limited to:

DRP ID

UDC ID

LSE ID

SAN


Effective End Date

Core

MSMEA DRRS

REGE-BRQ120

The system shall accept two locations with the same SAN and UDC as long as the effective dates do not overlap.

Core

MSMEA DRRS


ISO Public


Technology






Requirement Type



Impacted

REGE-BRQ122

Master File shall maintain a mapping of available pnodes to SubLAPs. This will be used for mapping Custom DR Resources.

Note: Existing Functionality

Core

MCI MF

REGE-BRQ123

The system shall ignore the PNode location information submitted if the registration is requesting a pre-defined resource type.

Core

MSMEA DRRS

REGE-BRQ124

The system shall reference the list of pnodes mapped to corresponding SubLAPs from the Master File for pnode validation.

Core

MSMEA DRRS

REGE-BRQ125

The system shall ensure that all parameters that are presented as drop down list for selection shall be sorted in ascending order.

Core

MSMEA DRRS

REGE-BRQ126

The DRP shall provide the pnode for a location if the DRP would be using this location to request for a custom PDR/RDRR resource

Note: If no pnode information for the location is provided, the system shall only provide the option of choosing a pre-defined resource at the time of registering this location

Core

MSMEA DRRS

REGE-BRQ128

The system shall validate the pnode information for the location with reference to the associated SubLAP that is maintained in the Master File.

Note: The system shall reject the submission if the given pnode for a location does not match the SubLAP in the Master File. This requirement relates to API functionality.

Core

MSMEA, MCI

DRRS, MF

REGE-BRQ130

The LRCV of a location shall be entered in kW and shall be greater than zero (ie., positive non-zero values). The LRCV shall allow for two significant digits after the decimal (for example 12.46 kW).

Core

MSMEA DRRS

REGE-BRQ132

Street address shall be alphanumeric and may contain special characters upto a maximum of 255 characters

Core

MSMEA DRRS


ISO Public


Technology






Requirement Type



Impacted

REGE-BRQ134

City shall be alphanumeric and may contain special characters upto a maximum of 255 characters.

Core

MSMEA DRRS

REGE-BRQ136

Zip code shall be limited to 10 characters, including numbers and a hyphen and will follow the format of XXXXX-XXXX, where X represents a number. The numbers following the hyphen are optional.

Core

MSMEA DRRS

REGE-BRQ138

State shall be provided as a drop down list on the UI. When submitted using the API, the State shall be validated against the standard list of states within USA

Core

MSMEA DRRS

REGE-BRQ140

UI Effective Dating Validation

The DRRS shall ensure that the entered effective start and end dates are valid among the location identification values including DRP ID, UDC ID, LSE ID, SubLAP, Pnodes. In other words, the UI shall only populate effective DRP IDs, UDC IDs, LSE IDs, SubLAPs, and Pnodes that are effective in the prescribed time horizon.

Core

MSMEA, MCI

DRRS, MF

REGE-BRQ142

API Effective Dating Validation

The DRRS shall ensure that the submitted effective start and end dates are valid among the location identification values including DRP ID, UDC ID, LSE ID, SubLAP, Pnodes. In other words, the API shall validate that the DRP IDs, UDC IDs, LSE IDs, SubLAPs, and Pnodes are effective in the prescribed time horizon.

Core

MSMEA, MCI

DRRS, MF

REGE-BRQ144

The system shall ensure that the DRP ID being entered is valid based on user credentials. In other words, the system shall ensure that the DRP ID being entered or submitted for locations matches with one of the DRP IDs provisioned on the certificate being presented.

Core

MSMEA DRRS


ISO Public


Technology






Requirement Type



Impacted

REGE-BRQ146

Effective start and end dates are true date fields with no time component. In other words, effective days will happen at a day boundary.

Note: Dates shall be systematically represented in GMT, while the user interface will represent dates in whole days.

Core

MSMEA DRRS

REGE-BRQ148

The system shall provide the ability for the DRP to end date a location such that the location is no longer active.

Core

MSMEA DRRS

REGE-BRQ150

Business Rule: A Location cannot be created with a start date in the past. In other words, new locations are effective at the earliest on the day they are created.

Core

MSMEA DRRS

REGE-BRQ152

Business Rule: A location cannot be created with an End Date that is less than the effective start date.

Core

MSMEA DRRS

REGE-BRQ154

Business Rule: The end date of a location can be in the past as long as it is greater than or equal to the start date and as long as it does not precede the last effective end date of a registration it was associated with.

Core

MSMEA DRRS

REGE-BRQ156

Business Rule: A location could be effective for one day such that the start and end dates are the same (no intra-day effective dating).

Core

MSMEA DRRS

REGE-BRQ158

A location may not overlap effective dates based on unique attributes as listed in requirement EDR3-BRQ915 . On any given date, a single location may only be effective once.

Core

MSMEA DRRS

REGE-BRQ160

The system shall allow for the DRP to either Save or Save & Submit the location(s) that they create for review. The ISO will have visibility to the Saved locations that have not yet been submiited for review.

Note: Multiple locations can be submitted for review using the API. The UI action will be on individual locations

Core

MSMEA DRRS


ISO Public


Technology






Requirement Type



Impacted

REGE-BRQ162

The system shall ensure that locations created using a given DRP ID are able to be viewed and/or modified by user/certs that have the same DRP ID provisioned for access.

Core

MSMEA DRRS

REGE-BRQ164

The system shall allow for a mechanism for the LSE and UDC assigned to a location to review the location information and provide comments, if any.

Note: The system shall ensure that the LSE and UDC are able to review only those locations to which they have specifically been assigned these roles. In other words, irrespective of the DRP ID, the LSE and/or UDC, they should be able to view all locations that have been assigned to them.

Core

MSMEA DRRS

REGE-BRQ166

The system shall allow the concurrent LSE and UDC review period to be a configurable number of days (Review period) to review the location information submitted by the DRP. If the review is not completed within the review period, the location shall be automatically processed and is available to the DRP for further action.

Note: The configurable review period shall be set at 10 business days for the initial implementation.

Core

MSMEA DRRS

REGE-BRQ168

If the LSE or UDC enters a comment during the review period, the system shall continue to hold the location in a pending status such that the location is not available to the DRP for registration.

Core

MSMEA DRRS

REGE-BRQ170

If the LSE or UDC enters a comment on a location, the DRP that owns the location shall be automatically notified with the full details entered by the LSE or UDC

Core

MSMEA DRRS

REGE-BRQ172

If the DRP makes changes to the location based on the comments provided by the LSE or UDC and submits for review, a new review process will be initiated for that particular location.

Core

MSMEA DRRS

REGE-BRQ174

The process of issue resolution for a location between the LSE or UDC and the DRP shall be handled outside the ISO.

Business Process

N/A N/A


ISO Public


Technology






Requirement Type



Impacted

REGE-BRQ176

A DRP can enter location(s) without automatically submitting them for review. If a location is not submitted for review, the DRP is able to edit the location data or delete the entire location without requiring any actions by the LSE or UDC.

Core

MSMEA DRRS

REGE-BRQ178

Once a location is submitted for review, the DRP does not have the ability to modify the location in any way. If, during the approval process, the DRP discovers an error in the location data or needs to change the location in any way, the DRP can cancel the location review request or retract the location.

Core

MSMEA DRRS

REGE-BRQ180

The system shall ensure that the LSE and UDC review process is cancelled if the DRP decides to retract the location during the review period.

Core

MSMEA DRRS

REGE-BRQ182

The system shall ensure that any location that has been retracted during the review period is provided with a distinct meaningful status.

Core

MSMEA DRRS

REGE-BRQ184

The system shall provide a mechanism for the DRP to copy existing location to create a new location by making modifications to the copied location.

Core

MSMEA DRRS

REGE-BRQ186

In the event that a location is entered or modified such that all the required attributes match those of an already entered location for the same effective date range, the new location status will be marked as duplicate. The DRP of the duplicate location will be notifed with an error message providing details of the already existing location that includes but not limited to:

DRP ID

UDC ID

LSE ID

SAN


Effective End Date

Core

MSMEA DRRS


ISO Public


Technology






Requirement Type



Impacted

REGE-BRQ188

The system shall also notify the DRP (incumbent DRP) of the location that is currently active that a duplicate location has been entered.

Core

MSMEA DRRS

REGE-BRQ190

The system shall allow the incumbent DRP a configurable number of days (defense period) to defend the location by providing a comment. If no action is taken by the incumbent DRP within the defense period, the current location shall be end dated in order to allow the new location to be submitted for review. If this location is part of an active registration, this will also change the status of the registration.

Note: The configurable defense period shall be set at 10 business days for the initial implementation.

Core

MSMEA DRRS

REGE-BRQ192

If the incumbent DRP enters a comment in defense of the location during the defense period, the system shall not end date the current location and will continue to keep the newly entered location as a Duplicate.

Core

MSMEA DRRS

REGE-BRQ194

The process of issue resolution for a location between the two DRPs shall be handled outside the ISO

Business Process

N/A N/A

REGE-BRQ196

When an LSE and UDC enters a comment during the review period, or when a DRP enters a comment during the defense period, the system shall require a contact name and number to be entered such that the details can be included in the automatic notification process.

Core

MSMEA DRRS


ISO Public


Technology






Requirement Type



Impacted

REGE-BRQ198

Modifying Locations: The system shall allow the DRP to edit any of the location attributes if the location has not yet been submitted for LSE and UDC review The system shall allow the DRP to retract the location if any changes are needed after they submit the location for review. The system shall allow the DRP to change the LRCV of an existing location that has been reviewed without having to submit the location for review. Once a location is reviewed and prior to registration:

The system shall allow the DRP to make changes to the following fields without having to submit for review:

Location Name,

LRCV,

Address Fields,

Effective start date to be greater than the current start date

Effective end date to be less than the current end date.

If any of the following attributes require a change, the registration requires termination and a new registration needs to be created. The termination will honor the 5 business day Master File SLA.

UDC ID, LSE ID, SubLAP, PNode, SAN, Effective start date to be less than the current start date, Effective end date to be greater than the current end date.

Once a location is reviewed and is part of a registration: The system shall allow the DRP to make changes to the following fields without affecting the status of the registration:

Location Name,

Address Fields,

LRCV, only if: i. the new location LRCV is greater than

the current location LRCV ii. the difference between the new LRCV

of the registration that contains this location and the pMax of the resource assigned to this registration in the Master File is less than or equal to 2 MW.

If the above two conditions are not met, the system shall require the DRP to end date the existing location, which will trigger a change to the registration end date as per REGE-BRQ232.

Core

MSMEA DRRS


ISO Public


Technology





4.2 Business Process: Manage Registrations



Requirement Type



Impacted

REGE-BRQ200

The system shall provide a user interface (UI) and an automatic programming interface (API) for the DRPs to create, modify and remove registrations

Core

MSMEA DRRS

REGE-BRQ202

The system shall provide an interface (and API) allowing the DRP the ability to provide the following registration information:

DRP ID (unique)

UDC ID (unique)

LSE ID (unique)

SubLAP (unique)

Registration Name


Effective End Date

DLAP

DRP SC ID

Program (For example, Proxy DR or Reliability DR)

Resource Type (For example, Custom or Pre-Defined)

Resource ID (optional)

Baseline Method

Note: All Registration data fields except Resource ID are mandatory.

Core

MSMEA DRRS

REGE-BRQ204

The system shall provide the list of all available resource IDs based on the other registration attributes provided by the DRP and by referencing the Master File mapping for the resource IDs.

Core

MSMEA, MCI

DRRS, MF


ISO Public


Technology






Requirement Type



Impacted

REGE-BRQ206

When submitting a registration using the API, the DRP may provide the resource ID that is assigned to them, which will be validated against the Master File reference data. If the DRP leaves the field blank, the ISO will assign a resource ID.

Note: The time required for the ISO to assign a pre-defined resource is much less than the one required to assign a custom resource.

Core

MSMEA DRRS

REGE-BRQ208

The system shall maintain a list of all available predefined (ie., not tied to a pending or active registration) resource IDs such that either the DRP (based on REGE-BRQ202 ) or the ISO is able to assign resource IDs to registrations.

The system shall ensure that a location is not used in multiple registrations or cannot be used in both a PDR and RDRR registration at the same time.

Core

MCI, MSMEA

MF, DRRS

REGE-BRQ209

System shall alert DRP when there is a location being used in another registration during the registrations effective date when submitting.

Core

MSMEA DRRS

REGE-BRQ210

The system shall automatically derive and present the LSE SC ID based on the DLAP information provided in the registration.

Core

MSMEA DRRS

REGE-BRQ212

The system shall perform the following UI data validations upon location creation:

Valid DRP ID, UDC ID, LSE ID, SubLAP,DRP SC ID, DLAP and Resource IDs shall be made available for selection based on Master File data (drop down list, no free form text)

Core

MSMEA, MCI

MF, DRRS

REGE-BRQ214

When submitting location data via an API, the system shall ensure that the following data elements are valid against the Master File:

DRP ID, UDC ID, LSE ID, SubLAP,DRP SC ID, DLAP and Resource IDs

Core

MSMEA, MCI

MF, DRRS

REGE-BRQ216

The system shall enforce a unique identifier for registrations to prevent duplicate or overlapping registrations

Core

MSMEA DRRS


ISO Public


Technology






Requirement Type



Impacted

REGE-BRQ218

Registration Name can contain alphanumeric and special characters, upto a maximum of 255 characters

Core

MSMEA DRRS

REGE-BRQ220

The system shall ensure that the DRP ID being entered is valid based on user credentials. In other words, the system shall ensure that the DRP ID being entered or submitted for registrations matches with one of the DRP IDs provisioned on the certificate being presented.

Core

MSMEA DRRS

REGE-BRQ222

Effective start and end dates are true date fields with no time component. In other words, effective days will happen at a day boundary.

Note: Dates shall be systematically represented in GMT, while the user interface will represent dates in whole days.

Core

MSMEA DRRS

REGE-BRQ224

The system shall provide the ability for the DRP to end date a registration such that the registration is no longer active.

Core

MSMEA DRRS

REGE-BRQ226

The system shall ensure that any registration that has been end dated is provided with a distinct meaningful status.

Core

MSMEA DRRS

REGE-BRQ228

Business Rule: A registration cannot be created with a start date in the past. In other words, new registrations are effective at the earliest on the day they are created.

Core

MSMEA DRRS

REGE-BRQ230

Business Rule: A registration cannot be created with an End Date that is less than the effective start date.

Core

MSMEA DRRS

REGE-BRQ232

Business Rule: At the earliest, the registration shall be end dated five business days from the current date in the case when the termination is required due to Master File resource attributes updates.

Note: 5 business days’ latency is the current Master File SLA.

Core

MSMEA DRRS


ISO Public


Technology






Requirement Type



Impacted

REGE-BRQ234

Business Rule: A registration could be effective for one day such that the start and end dates are the same (no intra-day effective dating).

Core

MSMEA DRRS

REGE-BRQ236

A registration may not overlap effective dates based on unique attributes as listed in requirement REGE-BRQ202. On any given date, a single registration may only be effective once.

Core

MSMEA DRRS

REGE-BRQ238

The system shall ensure that a given DRP is only able to view and/or modify those registrations that have been created by them

Core

MSMEA DRRS

REGE-BRQ240

A DRP can enter and save registration(s) without automatically submitting them. If a registration is not submitted, the DRP is able to edit the registration data or delete the entire registration. Note: Multiple registrations can be submitted using the API. The UI action will be on individual registrations

Core

MSMEA DRRS

REGE-BRQ242

The system shall retain the unsubmitted registration in a pending status until the registration is submitted.

Core

MSMEA DRRS

REGE-BRQ244

The system shall provide a mechanism for the DRP to copy existing registration to create a new registration by making modifications to the copied registration.

Core

MSMEA DRRS

REGE-BRQ246

The system shall ensure that the following data elements are the same for all locations participating in a single registration: DRP ID, UDC ID, LSE ID, SubLAP

Core

MSMEA DRRS

REGE-BRQ248

The system shall ensure that only those locations that have the effective start and end dates that are equal to or fall within the registration start and end dates are available for that registration creation.

Core

MSMEA DRRS


ISO Public


Technology






Requirement Type



Impacted

REGE-BRQ250

Once a registration is active, the location end date can only be contracted until the end date of the registration. Error Handling: The system shall notify via an error message the DRP in both the API and UI when a location end date is contracted less than the registration end date.

Core

MSMEA DRRS

REGE-BRQ252

Based on the data presented by the DRP as listed in REGE-BRQ202, the system shall present only those set of locations that are available for registration.

Core

MSMEA DRRS

REGE-BRQ254

The system shall ensure that all parameters that are presented as drop down list for selection shall be sorted in ascending order.

Core

MSMEA DRRS

REGE-BRQ256

The system shall provide the following two options for DR Program:

Proxy DR

Reliability DR

Core

MSMEA DRRS

REGE-BRQ258

If the Proxy DR is selected, the system shall ensure that the registration LRCV is greater than or equal to 100 kW.

Core

MSMEA DRRS

REGE-BRQ260

If the Reliability DR is selected, the system shall ensure that the registration LRCV is greater than or equal to 500 kW.

Core

MSMEA DRRS

REGE-BRQ262

The system shall provide the following two options for the Resource Type:

Pre-defined

Custom

Core

MSMEA DRRS

REGE-BRQ264

The system shall provide the following options for Baseline Method:

10 in 10

”Statistical Sampling” or other methodology Note: This requirement will not implement a baseline methodology, but rather will provide infrastructure for future implementation and integration into the current DRS. A policy initiative is ongoing to define any or all additional baseline methodologies.

Core

MSMEA DRRS

REGE-BRQ266

The system shall ensure that the Resource ID field is not available for selection if custom resource type is selected.

Core

MSMEA DRRS


ISO Public


Technology






Requirement Type



Impacted

REGE-BRQ268

The system shall ensure that only those locations that meet the unique attributes as described in BRQ202 and that have the pnode information available are presented for creating a registration with resource type selected as Custom.

Core

MSMEA DRRS

REGE-BRQ270

If a Custom Resource is requested for a registration, the system shall provide to Master File the total of LRCV per pnode in the registration. This will be used by Master File to derive the generation distribution factors (GDF) for the registration/resource.

Core

MSMEA, MCI

DRRS, MF

REGE-BRQ272

Effective Dating management between MF resources and DR Registrations.

Assumption: A resource with no active registration shall not be made available to the market.

When a DR registration is end dated via end date contraction or Pmax tolerance violation, the system shall automatically generate an email-based notification to Model Contract & Implementation (MCI) that the MF resource needs to be end dated with the same end date as the registration.

Note: This prevents the resource from bidding in the market outside the registration period.

Core

MSMEA, MCI

DRRS, MF

REGE-BRQ274

The system shall automatically sum the LRCV of the locations being selected to derive the LRCV of the registration. Registration LRCV will be displayed in kW and shall be greater than zero (ie., positive non-zero values).

The system shall make available the registration LRCV for DRP consumption (IU and API methods).

Core

MSMEA DRRS


ISO Public


Technology






Requirement Type



Impacted

REGE-BRQ276

Modifiying Registrations: The system shall allow the DRP to edit any of the registration attributes if the registration has not yet been submitted. Once a registration is submitted but not yet confirmed:

The system shall allow the DRP to make changes to the following fields:

Registration Name,

Effective start date to be greater than the current start date

Effective end date to be less than the current end date.

If any of the following attributes require a change, the registration requires termination and a new registration needs to be created.

UDC ID, LSE ID, SubLAP, DLAP, DRP SCID, Effective start date to be less than the current start date, Effective end date to be greater than the current end date.

Once a registration is confirmed (assigned a Resource ID):

The system shall allow the DRP to make changes to the following fields without affecting the status of the registration:

Registration Name,

Effective end date to be less than the current end date

Core

MSMEA DRRS

REGE-BRQ278

RDRR seasonality: For RDRR Discrete dispatch resources: All seasons will have a start/end date for the program. There are two seasons defined per year namely summer and winter. No resource discrete status overlap is allowed between seasons. Discrete/non-discrete status shall be maintained throughout the season. The resource may select “All Seasons” which holds discrete status into perpetuity or until updated by the DRP. Master File shall maintain the discrete dispatch flag and association with the RDRR seasons as described above.

Core

MCI MF


ISO Public


Technology






Requirement Type



Impacted

REGE-BRQ280

Custom Resources: If a registration is created with a request for a custom Resource ID, the system shall automatically notify the FNM team of the request including all required info (Pnode and LRCV for each registration) so they may initiate creating the custom resource ID in the next model build.

Core

MSMEA, FNM

DRRS

4.3 Business Process: Manage Resources



Requirement Type



Impacted

REGE-BRQ300

A PDR or RDRR Resource must be represented by only one DRP.

Core

MSMEA DRRS

REGE-BRQ302

The system shall be capable of assigning one resource per registration in a given time period.

Note: There may be a future need to provide flexibility to include multiple registrations under the same resource in the context of allowing locations across multiple LSEs to participate in a single registration.

Core

MSMEA DRRS

REGE-BRQ304

Business Rule: For a given resource, The system shall track LRCV at the registration level such that the Resource Pmax must be no greater than 2MW above the Registration LRCV.

The resource Pmax may be less than Registration LRCV.

The DRP may remove and/or add locations while observing the 2MW rule mentioned above.

Note: Relaxing the Pmax validation to within 2 MW allows for DRP flexibility to dynamically update resource location configurations.

Core

MSMEA DRRS


ISO Public


Technology






Requirement Type



Impacted

REGE-BRQ306

Business Rule:If the Master File PMAX and the DRRS registration LRCV have a difference greater than 2 MW, then the corresponding registration and Master File resource shall be terminated immediately.

Note: See previous business rule for context.

Core

MSMEA DRRS

REGE-BRQ306

Business Rule: If the DRP creates a Proxy DR registration, the system shall check for the LRCV of the aggregated registration value. If this value is greater than or equal to 10MW, the system shall not allow for the DRP to select a resource ID as well as send a notification to the PDR Coordinator for metering requirement purposes. The PDR Coordinator will assign a resource ID after checking the telemetry requirements.

Core

MSMEA DRRS

REGE-BRQ307

The system shall allow the PDR coordinator visibility into draft registrations.

Core

MSMEA DRRS

REGE-BRQ308

The system shall allow the creation of a draft registration. A draft registration is an inactive registration that is waiting for a corresponding Master File Resource update to become effective.

Core

MSMEA DRRS

REGE-BRQ310

If a resource is reserved for a draft registration, that resource ID has been committed and no other registration may use that resource.

Core

MSMEA DRRS

REGE-BRQ311

A draft registration must reserve a resource and that resource must provide registration attributes that match the Master File-based resource attributes.

Core

MSMEA DRRS


ISO Public


Technology






Requirement Type



Impacted

REGE-BRQ312

Business Rule: A resource may be reserved for up to a maximum of 30 days from the date of draft reservation creation. If the registration is not submitted in the 30 day period, the resource shall be released from the draft registration.

Core

MSMEA DRRS

REGE-BRQ314

Dependency: A draft registration may not associate to a resource until it has been defined in Master File. This dependency rule shall be enforced in DRRS.

Business Process

MSMEA DRRS

REGE-BRQ316

Validation: A draft registration becomes effective when it matches the new effective Master File-based resource attributes including Pmax.

Note: A resource effective and termination date are allowed to be different from a registration start and end date. Resource effective date may lie between the registration start and end dates. Resource end date and registration end date must match.

Validation reasoning: It is acceptable for a resource start date to be greater than the registration start date since there are no operational hazards. Although a registration may be active, the resource bidding ability will not be negatively affected. This latency allows for the RDT input to catch up to the registration.

Core

MSMEA DRRS

REGE-BRQ318

Business Rule: The DRRS shall not maintain either discrete dispatch flag for reliability resources or Day-Ahead-only flag for Proxy DR resources. This will now be provided by the DRP on the RDT and maintained by Master File.

Business Process

MCI MF

REGE-BRQ320

The system shall track the number of pre-defined resources that are available per SubLAP and send an automatic notification to the PDR Coordinator and FNM team when this number reaches less than 10 resources per sublap in order to initiate creation of 10 new resources in the next model build.

PDR/RDRR Resource ID naming convention:

<sublap name>_<Voltage code>_<PDRP/RDRRxx>

Core

MSMEA DRRS


ISO Public


Technology






Requirement Type



Impacted

REGE-BRQ321

The system shall allow the PDR Coordinator to input the newly created pre-defined resources as described in REGE-BRQ320.

Core

MSMEA DRRS

REGE-BRQ322

The system shall track and make available resource IDs that are associated with active and inactive resource IDs so that the system can maintain a list of available resource IDs for selection by the DRP or the ISO.

Core

MSMEA DRRS

REGE-BRQ326

PDR RDRR Mutual Exclusivity

If a Proxy DR resource is associated with a registration, then the corresponding Reliability DR resource shall be removed from the list of available resources. In converse, if a Reliability Resource is associated with a registration then the corresponding Proxy DR resource shall be removed from the list of available resources.

Core

MSMEA DRRS

REGE-BRQ328

Once a resource has been registered, the system shall send the following registered resource identifying information to Master File for use in creating the resource:

DRRS info: UDC ID, LSE ID, DRP SC ID, SubLap, DLAP, Program (DR Proxy or DR Reliability) , Resource ID, Effective Start Date, Effective End Date, LRCV.

Core

MSMEA, MCI

DRRS, MF

REGE-BRQ330

Once a registration has committed a resource, the DRP shall input the relevant resource attributes in the Master File GRDT.

Business Process

N/A N/A

Business Requirements Specification Requirements Specification ... as the initial set of business unit requirements for the appropriate software ... phase will address and enhance

Documents