Customer Partnership Group May 12, 2015 Presented by: Mike Lucas, - - PowerPoint PPT Presentation

California ISO

Demand Response Registration System Customer Partnership Group May 12, 2015

Presented by: Mike Lucas, Project Manager Tarak Thaker, Business Analyst Indu Nambiar, Business Solutions Manager ISO SME’s

California ISO

Support the continued development of the Demand Response Registration System (DRRS) used for proxy demand resource and reliability demand response resource participation.

Customer partnership group kick off

2

Changes that require policy decisions and/or tariff changes will be taken up in a separate stakeholder effort

California ISO

Background on DRRS and DRS development plan initiated in 2014

3

California ISO

The demand response system was developed to support:

• Location Management
• Registration Management
• Meter Data Management
• Baseline Calculation
• Performance Calculation
• Settlement

ISO developed system functionalities for wholesale demand response participation

4

California ISO

Identified API’s needed for bulk loading and downloading

• Locations – Create, Modify, Terminate
• Registrations – Create, Modify, Terminate
• Baseline Calculation Data – Retrieve
• Performance Data – Retrieve

System enhancements have been requested to enable increased participant use and satisfaction

5

UI and API provided for system functionality will not meet needs of all programs

Market Participants have requested capability to integrate all residential and non-residential programs consisting of thousands of accounts (locations) Greatest impact Flexibility needed

California ISO

Last years short term goal (Implemented April 2015)

• Develop API’s for location management to gain process efficiency
• Manage system and process challenges of API’s use
• Accommodate program integration with known demand response system limitations
• Ensure short term enhancements are in step with organizations architectural goals

Long Term

• Integration of functional components of demand response with mainstream applications
• Incorporate system improvements to reduce barrier to DR integration identified in CPUC

working groups

• Maintain and enhance existing functionalities, provide additional capabilities
• Standardized APIs
• Unified UIs and APIs when possible

What CAISO has achieved and continues to work on:

6

California ISO

DRRS Functionality Consolidation & Timeline

7

Settlement Location Management Resource Management Registration Management Meter Data Management Baseline, Performance & Compliance Calculation

Integration with Location & Registration Management

API

2014 2015 2016 2017

Integrated with CAISO’s NEW Metering Solution

2014 2015 2016 2017

Unified UI with Location Management

Integrated with CAISO’s Settlement Application

API for Submit & Retrieve

UI

Phase 2 Phase 3 Phase 1 Delivered earlier in 2016

California ISO

Additional concepts being considered for Phase 2 to meet objectives

• Registration review process occurring at the location level
• Reducing the review process timeline based on stakeholder

feedback

• Providing registration modification flexibility to eliminate or

minimize resource participation interruptions

• Relaxing certain system requirements around “seasonal

terms” affecting reliability demand response resource registration

• Leveraging aggregate location (ALOC) construct for potential

aggregation requirement modifications (ie. across LSE, one to many resource to registration, baseline application)

California ISO

BRS Name

Rules Functionality PDR BRS

• PDR Resource Rules
• Location-based registration behavior

via rules for PDR

• Process Definition
• Process Implementation
• DRRS <--> MF Mapping
• DRS <--> DRRS Mapping
• Registration APIs

RDRR BRS

• RDRR Resource Rules
• Location-based registration behavior

via rules for RDRR.

• Process Definition
• PDR/RDRR Mutual Exclusivity during

registration & resource creation

• Process Implementation
• DRRS <--> MF Mapping
• DRS <--> DRRS Mapping
• Registration APIs

DR Location Registration Enhancement BRS

• Registration to location rules
• Locations Defined
• ALOC Defined
• ALOC Location creation

Functionality

• Validation Requirements
• Reg --> Location validation

BRS Topic Areas – Phase 2

9

California ISO

BRS Name

Rules Functionality PDR BRS

• Meter Data Rule

enforcement

• Baseline calc rule

enforcement

• Baseline

Calculation

• Accept, store, and communicate registration-based load or gen

Settlement Quality Meter Data (SQMD)

• Submit & retrieve meter data via APIs based on appropriate roles
• API for all applicable settlement attributes pertaining to DR, on a role

basis.

• Settlements calculated resource performance and DR Energy

Measurement

• Existing baseline calculations (10 in 10 algorithm & others)
• Any new Baseline calculations in Settlements systems
• Support One resource to multiple registrations and their corresponding

baseline calc methodologies

• Use gen outage info from OMS for baseline calc
• Display DR events

RDRR BRS •

Same as PDR

• Same as PDR

BRS Topic Areas – Phase 3

10

California ISO

Function

Phase 2 Phase 3 BRS Creation

• Location-based

Registration

• LR to Resource ID

Mapping

• Entity Relationship

Modeling for Meter Data & Baseline

• Location Registration API
• Meter Data definition & Functionality
• Settlements functionality
• Baseline calculations
• Utilize the Meter Data & Baseline modeling from

Phase A here

Implement •

Location Registration implementation

• Resource ID mapping

API/UIs

• Meter Data
• Settlements (including Baseline)

BRS to Development Mapping

11

California ISO

Today’s Phase 2 design and process topics for discussion

• Location Profile
• Custom Resources – PNode required
• LSE & UDC Location review timeline
• Location cardinality
• DRRS User Interface

California ISO

Stakeholder Design Questions: Location Profile

• Do users want the DRRS to manage location profile info

(A/C, Lighting, Refrigeration, etc.)?

– If profile is kept, the breakdown will be aggregated to derive the location load reduction curtailment value (LRCV) – If profile is removed, then users will enter a single LRCV for the location

California ISO

Stakeholder Design Questions: PNODE as a required field for location creation:

• What do stakeholders think about making the PNode

field mandatory?

• Required information for custom resources – making it a

mandatory field will provide efficiency in requests for custom PDR/RDRR

• PNodes and LRCV per PNode information for a registration can

derive and provide information required for the modeling process

California ISO

Stakeholder Design Questions: LSE & UDC Location Review

• Based on voice of the customer input, the ISO

recommends a 4 business days concurrent UDC and LSE review period for location

– Reduces current 10 business day review process to 4 business days, with auto approve occurring in that timeframe

• What are stakeholder’s thoughts?

California ISO

Stakeholder Design Questions: Location Validation: SAN & UDC cardinality

• Currently location cardinality validation requires all SANs

to be unique

• Proposed validation: use both UDC and SAN together to

check for uniqueness

California ISO

Stakeholder Design Questions: Location User interface: DLAP filtering

• Current system filters DLAP based on SubLap
• Any additional filtering would require LSE SCID

identification

– To identify would require a larger selection, more prone to error

• Sorted list of current DLAP selection will be made

available as an alternative resolution

California ISO

Stakeholder Design Questions: DRRS User interface: RDRR season enforcement and discrete dispatch flag, PDR/RDRR Day ahead

• nly flag
• Relax season enforcement in DRRS for RDRR

– Need ability to modify RDRR during seasons – Do not enforce discrete dispatch for entire season – Seasons are no longer needed if enforcement is not through registration

• Term availability requirements will remain but

enforcement or reporting will not be at registration

California ISO

Next Steps

19

• ISO Continued development of Phase 2 draft BRS
• May 2015
• Publish phase 2 draft BRS to participants
• By end of May 2015
• Hold CPG call to obtain feedback/input and continue

BRS development discussion

• June 4, 1-4 PM