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
Customer partnership group kick off Support the continued development of the Demand Response Registration System (DRRS) used for proxy demand resource and reliability demand response resource participation. Changes that require policy decisions and/or tariff changes will be taken up in a separate stakeholder effort California ISO 2
Background on DRRS and DRS development plan initiated in 2014 California ISO 3
ISO developed system functionalities for wholesale demand response participation The demand response system was developed to support: • Location Management • Registration Management • Meter Data Management • Baseline Calculation • Performance Calculation • Settlement California ISO 4
System enhancements have been requested to enable increased participant use and satisfaction 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) Identified API’s needed for bulk loading and downloading • Locations – Create, Modify, Terminate Greatest impact • Registrations – Create, Modify, Terminate Flexibility needed • Baseline Calculation Data – Retrieve • Performance Data – Retrieve California ISO 5
What CAISO has achieved and continues to work on: 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 California ISO 6
DRRS Functionality Consolidation & Timeline 2014 2015 2016 2017 UI Location Management Phase 1 API Unified UI with Location Management Phase 2 Registration Management API for Submit & Retrieve Delivered earlier in 2016 Integration with Location & Resource Management Registration Management Integrated with CAISO’s NEW Meter Data Management Metering Solution Phase 3 Baseline, Performance & Compliance Calculation Integrated with CAISO’s Settlement Application Settlement 2014 2015 2016 2017 California ISO 7
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 Topic Areas – Phase 2 BRS Name Rules Functionality • PDR Resource Rules • Process Implementation • Location-based registration behavior • DRRS <--> MF Mapping via rules for PDR PDR BRS • DRS <--> DRRS Mapping • Process Definition • Registration APIs • RDRR Resource Rules • • Location-based registration behavior Process Implementation via rules for RDRR. • DRRS <--> MF Mapping • Process Definition RDRR BRS • DRS <--> DRRS Mapping • PDR/RDRR Mutual Exclusivity during • registration & resource creation Registration APIs • ALOC Location creation • Registration to location rules DR Location Functionality • Registration Locations Defined • Validation Requirements Enhancement BRS • ALOC Defined • Reg --> Location validation California ISO 9
BRS Topic Areas – Phase 3 BRS Name Rules Functionality • 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) • Meter Data Rule • Any new Baseline calculations in Settlements systems enforcement PDR BRS • Support One resource to multiple registrations and their corresponding • Baseline calc rule baseline calc methodologies enforcement • Use gen outage info from OMS for baseline calc • Baseline Calculation • Display DR events RDRR BRS • • Same as PDR Same as PDR California ISO 10
BRS to Development Mapping Function Phase 2 Phase 3 • Location-based • Registration Meter Data definition & Functionality BRS • • LR to Resource ID Settlements functionality Mapping Creation • Baseline calculations • Entity Relationship • Modeling for Meter Data Utilize the Meter Data & Baseline modeling from & Baseline Phase A here • Location Registration API Implement • • Location Registration Meter Data implementation • Settlements (including Baseline) • Resource ID mapping API/UIs California ISO 11
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 only 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 • 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 California ISO 19
Recommend
More recommend
