· Web viewmay have available to host DERs. Assigned Commissioners Ruling, November 2014. ( Pursuant

California Distribution Resources Plan Integration Capacity Analysis Working Group

DRAFT Final Report – Due March 15, 2017

NOTE: This is a third draft of the report. The WG will discuss the report as a group on 3/9.

Table of Contents1 Executive Summary.............................................................................................................................2

2 Introduction and Background..............................................................................................................2

3 Discussion Topics, Points of Consensus, Proposed Alternatives if Any, Recommendations, Next Steps............................................................................................................................................................6

3.1 Use Cases of ICA..........................................................................................................................7

3.2 Development of Common IOU methodology............................................................................10

3.2.1 Overview............................................................................................................................10

3.2.2 Streamlined method..........................................................................................................11

3.2.3 Iterative method................................................................................................................11

3.2.4 Recommendations.............................................................................................................11

3.3 Schedule and Timelines.............................................................................................................13

3.3.1 Timeline for implementation.............................................................................................13

3.3.2 Recommended regulatory process....................................................................................15

3.4 Review of cost estimates...........................................................................................................15

3.5 Frequency of Updates................................................................................................................20

3.6 Presentation of ICA values.........................................................................................................21

3.7 ACR Requirements.....................................................................................................................21

3.7.1 Modeling and extracting power system data.....................................................................21

3.7.2 Power system criteria methodology..................................................................................22

3.7.3 Voltage regulation.............................................................................................................22

3.7.4 Safety/reliability, or “operational flexibility” ....................................................................23

3.7.5 Circuit models....................................................................................................................26

3.7.6 Pre-existing conditions.......................................................................................................26

3.8 Short-term activities..................................................................................................................27

3.8.1 ACR Section 3.1.b: Recommend methods for evaluation of hosting capacity for the following resource types: i) DER bundles or portfolios, responding to CAISO dispatch; ii) facilities using smart inverters.........................................................................................................................27

3.8.2 ACR Section 3.1.c: Recommend a format for the ICA maps and downloadable data to be consistent and readable by all California stakeholders across the utilities service territories with similar data and visual aspects (Color coding, mapping tools, etc.)...................................................29

3.8.3 ACR Section 3.1.d: Evaluate and recommend new methods that may improve the calculation of ICA values using computational efficiency method in order to calculate and update ICA values across all circuits in each utility’s service territory...........................................................30

1




3.8.4 ACR Section 3.1.e: Evaluate ORA’s recommendation to require establishment of reference circuits and reference use cases for comparative analyses of Demo Project A results......................31

3.8.5 ACR Section 3.1.f: Establish a method for use of Smart Meter and other customer load data to develop more localized load shapes to the extent that is not currently being done.............34

3.8.6 ACR Section3.1.g: Establish definite timelines for future achievement of ICA milestones, including frequency and process of ICA updates...............................................................................34

3.9 Long-term refinement activities................................................................................................34

3.10 Additional Cost Recovery...........................................................................................................35

3.11 Recommendation Summary Table.............................................................................................36

4 Next Steps for the ICA WG.................................................................................................................38

5 Appendix............................................................................................................................................40

5.1 Acronyms...................................................................................................................................40

5.2 Working Group Meetings and Topics.........................................................................................40

5.3 Working Group Participants.......................................................................................................41

1 Executive SummaryThis is the Final Demo A Report of the Integration Capacity Analysis (ICA) Working Group (WG) to the California Public Utilities Commission (CPUC). The report summarizes the development of the ICA to date, the recommended ICA methodology for the Investor Owned Utilities (IOUs) to implement across their service territories on the first system wide roll out, an implementation timeline, and recommendations on how to improve the methodology through the long-term enhancements via the ICA WG. This final report also provides recommendations on how the ICA results may be used to inform decision-making on the part of the Commission, utilities, providers of distributed energy resources, and customers.

2 Introduction and BackgroundOverviewAdopted in 2014, Section 769 of the California Public Utilities Code requires the Investor Owned Utilities (IOUs) to prepare a distribution resources plan, which identifies optimal locations for the deployment of distributed energy resources (DERs). In August 2014, the California Public Utilities Commission (CPUC, or Commission) began implementation of this requirement through Rulemaking (R.) 14-08-013, the Distribution Resources Plan (DRP) proceeding. A Ruling from the Assigned Commissioner in November 2014 introduced the Integration Capacity Analysis (ICA) as a tool that would support the determination of optimal locations by specifying how much capacity for integrating circuits on the distribution system

2

David, 03/05/17,

This section should be built out and expanded once everything else is finalized.

Laura Wang, 03/08/17,

Yes, will do so in final version of report!

Sky C. Stanfield, 03/04/17,

This is a fairly minor point, but with the luxury of time it might be nice to identify a consistent approach to whether “the” is used before ICA in many cases. I am not sure what the correct grammatical rule would be, but it seems inconsistent to use “the ICA” in some cases and just “ICA” in others. Similarly, at the end it might be worth doing a find/replace to make sure the references to the following items are consistent:-The Final Demo A Reports (final report, Demo A Reports, etc. are used)-The final WG report-Search for all the acronyms to make sure they are written out the first time (I added some) -




may have available to host DERs.1 Pursuant Commission direction, California’s Investor Owned Utilities (IOUs) filed their Distribution Resource Plans as Applications2 , including a proposal to complete a Demonstration of their ICA methodology (“Demo A”). Stakeholders provided input on the IOU proposals, leading to an Assigned Commissioner’s Ruling (ACR) issued in May 2016. That guidance authorized a demonstration project of the ICA, requiring the IOUs to meet the following nine functional requirements:

1. Quantify the Capability of the Distribution System to Host DER 2. Common Methodology Across All IOUs 3. Analyze Different Types of DERs 4. Line Section or Nodal Level on the Primary Distribution System 5. Thermal Ratings, Protection Limits, Power Quality (including Voltage), and Safety Standards6. Publish the Results via Online Maps7. Use Time Series Models 8. Avoid Heuristic approaches, where possible9. Perform the complete ICA analysis for all feeders down to the line section or node on two Distribution Planning Areas (DPA).3

The ACR also established the ICA Working Group (WG) to monitor and provide consultation to the IOUs on the execution of Demonstration Project A and further refinements to the ICA methodology. CPUC Energy Division staff has oversight responsibility of the working group, but it is currently managed by the utilities and interested stakeholders on an interim basis. The utilities jointly engaged More Than Smart (MTS), a 501(c)3 non-profit organization, to facilitate the WG. The Energy Division may at its discretion assume direct management of the working group or appoint a working group manager.

Between May 2016 and March 2017, the WG met 16 times. The WG has benefitted from contributions by a large range of stakeholders who are listed in Appendix A. The WG expects to continue its efforts through August 2017 as it begins to address long-term ICA refinement.

In December 2016, Pacific Gas & Electric (PG&E), Southern California Edison (SCE), and San Diego Gas and Electric (SDG&E) submitted their final Demo A reports, representing a substantial milestone for the demonstration projects.4 These reports summarize demo results, lessons learned, and the IOUs’ recommendations on the methodology selection and feasibility of implementation of the ICA across the entire distribution system.

Summary of Recommendations

1 Assigned Commissioners Ruling, November 2014. (http://docs.cpuc.ca.gov/PublishedDocs/Efile/G000/M141/K905/141905168.PDF)2 http://www.cpuc.ca.gov/General.aspx?id=5071 3 Assigned Commissioner’s Ruling, May 2016. (http://docs.cpuc.ca.gov/PublishedDocs/Efile/G000/M161/K474/161474143.PDF)4 IOU demo results can be found at: http://drpwg.org/sample-page/drp/

3


Technically we still need to file extension for LTR




This Final Report contains the full Working Group’s recommendations for the ICA methodology and related action items coming out of the IOU’s December filings. The WG offers recommendations on the methodology and timing considerations for the first system wide implementation, recommendations on how to improve the methodology through the long-term enhancements to ICA, and how the results may be used to inform decision-making on the part of the Commission, utilities, providers of distributed energy resources, and customers. At a high level, these include recommendations in the following four categories:

[1.] Uses of ICA: the WG identifies two primary use cases for the ICA. The first and most developed use case for the ICA is to improve interconnection, including a more automated and transparent significantly streamlined expedited Fast Track interconnection process and the publication of data that helps customers design systems that do not exceed grid limitations. The second and less developed use case for the ICA is to utilize it to inform distribution planning processes to help identify how to better integrate DERs onto the system. The WG report outlines near and long term methodological refinements to enable the use of ICA within the interconnection process, and lays out considerations for the planning use case, with a goal of developing methodology recommendations for use within the planning context in the near-term (and in coordination with ongoing planning proceedings at the CPUC).)

[2.] Development of Common IOU methodology: The ACR stated that the CPUC envisioned approving a final ICA methodology common across all utilities through a Proposed Decision in early 2017. The IOUs conducted the ICA using two separate methodologies in Demo A, known as “iterative” and “streamlined”. A majority of WG members, including SCE and SDG&E, recommend that the IOUs use the iterative methodology for interconnection purposes, assuming added refinements detailed further in this report can be achieved at a reasonable cost. PG&E recommends a “blended” approach using both methods for interconnection5. The WG believes the streamlined methodology may provide value in the planning process, and will continue to consider it while defining the uses of the ICA in system planning. The IOUs also recommend that each method may be more suited to specific circuits, situations, and tool capabilities and that blended use of both methods may be allowed where the utilities are not constrained to use a specific method that may not be optimal for all situations.

[3.] Timeline: As outlined in Section 3.3, the IOUs recommend to implement the ICA across their entire distribution service territories 12 months after PUC final decision on a common Commission-approved methodology. IOUs provided recommendations on when implementation should be completed, while some stakeholders offered a second perspective. The WG agrees that this first system-wide rollout should include the identified recommendations from this report.

[4.] Modifications to ICA methodology and schedule. The WG anticipates that it will conclude consideration of some of the outstanding issues soon, and that the IOUs will be able to implement some of those issues in the first system-wide rollout of ICA. The WG recommends that the Commission establish two three processes to incorporate modifications to the ICA: made during the long-term refinement phase of the WG, expected to conclude in late August 2017::

5 See PG&E’s final Demo A report: http://drpwg.org/wp-content/uploads/2016/07/R1408013-PGE-Demo-Projects-A-B-Final-Reports.pdf

4

Brandon Smithwood, 03/02/17,

I think this is an important clarification. Presumably there will be revisions in coming years. There should be an advice letter process for adoping those later (beyond 2017) modifications.


discussion

Roger Salas, 03/05/17,

Removed. Not sure what the intent of this was


Hi Nery, correct we currently do not have consensus on timing.

Nery Navarro, 03/05/17,

Is this in place because consensus wasn’t established? If not, we should add what the recommendation is at this point.


Changed to “improve”.


Brad Heavner:“Streamlined” doesn’t capture the benefit of giving customers data to design systems with the best fit to local capacity. This may be even more important than other process changes, and I worry that by using “streamlined” as the shorthand term this other benefit doesn’t get sufficient emphasis.

Brad Heavner, 03/04/17,

Streamlined and expedited mean roughly the same thing. We had simply been calling the use case “Interconnection” (See slide 8 from Aug 31 slides). This includes two things, which both need to be listed here – providing data and streamlining the process.


Brad Heavner:“Streamlined” doesn’t capture the benefit of giving customers data to design systems with the best fit to local capacity. This may be even more important than other process changes, and I worry that by using “streamlined” as the shorthand term this other benefit doesn’t get sufficient emphasis.


developed use case on its own sounded like there was actually some track record for use, so I put “case” back in.




1. A Working Group internal review process on long term refinements to ICA methodology. As the WG continues to refine and enhance the ICA methodology based on results of the studies for the components identified under the long-term enhancements to ICA section 3.8, it is requested that the Commission establish a process to allow the IOUs to make enhancements to the methodology as they are developed in consultation with the WG during the long-term refinement process. This process should provide flexibility to phase in refinements within boundaries established by the CPUC. The Commission should decide whether this process takes the form of a revised rulemaking, consultation with ICA WG or Energy Division staff, advice letter, etc.

[2.] Consultation with CPUC Energy Division on schedule for system wide implementation of ICA. The WG has developed recommendations on methodology refinements based on best available knowledge and in-depth discussions among a broad stakeholder group, though there are recommendations contingent upon costs and modeling software capabilities. It is requested that the Commission establish a process for the IOUs to consult with the Energy Division and issue a Tier 2 advice letter if one or more IOUs determines that a methodology component(s) cannot be included in the first system-wide rollout of ICA due to issues not possible to predict at this time and which are discovered during the rollout process (i.e. unexpected performance issues with software or tools). For those changes, the WG expects that IOUs will prioritize their resolution in the next iteration of ICA.

2. An additional CPUC decision prior to full system rollout. It is possible that unforeseen issues will arise that will need to be addressed via Commission decision prior to full system rollout of ICA. The CPUC should set a tentative timeline for such a decision.

Scope and Process

The “Working Group” references all active parties participating in ICA WG meetings, which include the IOUs, government representatives, DER developers, nonprofits, and independent advocates and consultants. All meeting dates and topics covered, as well as all stakeholder groups attending at least one meeting or webinar of the ICA WG, are described in Appendix A. This report is the product of significant edits and contributions from the following organizations:

- Artwell Electric Inc. - CPUC Energy Division

(ED)- CPUC Office of

Ratepayer Advocates (ORA)

- California Solar Energy Industries Association (CALSEIA)

- Clean Coalition (CC)

- Independent Advocates

- Interstate Renewable Energy Council (IREC)

- Pacific Gas & Electric (PG&E)

- San Diego Gas and Electric (SDG&E)

- Santa Barbara Community

Environmental Council

- SolarCity - Solar Energy

Industries Association (SEIA)

- Southern California Edison (SCE)

- The Utility Reform Network (TURN)

- Vote Solar

5


Please let me know if this list is appropriately indicative. I summarized based on submitted comments to both the report and the list of stakeholder questions developed in January/February.


Need to discuss with full WG, would need to add to Section 3.3.2 too


Agree on the proposed alterantive


Will revise after discussion for conformity with Section 3.3.2


There are a few options here for WG consideration. There is general agreement that process should be flexible and not unnecessarily burdensome. The WG can either 1.agree w/ consensus on a process, or 2. Let Commission decide on best process. Alternatively, IOUs propose: WG recommends that the CPUC establish a process by which IOUs could modify the planned scope and schedule of the ICA implementation by filing a Tier 1 Advice Letter. This process would allow changes to be formalized and visible to all parties, and the AL process provides an opportunity for stakeholders to formally respond to the modifications.IREC: I think an advice letter process is probably appropriate for the second area (i.e. where the IOUs are not able to do something that is expressly set out in the Commission’s order due to cost or other reasons) and likely for the first. I could be open to something less than an advice letter for “enhancements” to the ICA as long as they do not directly conflict with anything in the order, it seems like we do not want to tie the IOUs hands too much regarding minor tweaks to the maps, etc. that could make them more useful. Thus, the best way to resolve this might be a Tier 1 advice letter for both, but to clarify the nature of the “enhancements” that require the advice letter.




The ICA WG met regularly to discuss the proposed methodology for Demonstration A and to review the final Demo A reports. A full summary of WG documents including meeting agendas, presentation slides, and participant list is included in Appendix B.

All three IOUs submitted their Demo A reports at the end of December 2016 in compliance with the ACR, and made the maps and downloadable data available for stakeholder review. in January and February 2017. . These reports lay out in detail the assumptions and calculations used within the ICA methodology. Additional information about the methodology was shared during the subsequent WG meetings which dived into the details on numerous aspects of the process that had not be fully detailed in the reports. Additionally, the IOUs each separately made recommendations on which methodology (i.e., using a streamlined, iterative, or blended approach) to use going forward in a system-wide rollout of ICA. WG stakeholder review and further discussion of these recommendations led to different conclusions in some areas.

The ACR additionally specifies multiple items the WG should focus on to continue refining the ICA methodology. The WG filed an interim long-term refinement report in December 2016 detailing work to-date on those items, and sorting topics into a tiered system to develop a rough schedule for WG work in 2017. After reviewing the IOUs’ final Demo A reports, the WG identified additional long-term refinement items. Those items are included in an amended Table6, and the WG will prioritize this the development of this list at theas an action item during the beginning of its long-term refinement work. For the WG, “long-term refinement” means WG activity 6 months after the filing of this final report, beginning March 15, 2017 and ending September 15, 2017. .

To this end, the WG agrees to identify items where parties have built consensus, and to identify where there is non-consensus by particular parties and alternative proposals have been made.

3 Discussion Topics, Points of Consensus, Proposed Alternatives if Any, Recommendations, Next Steps

The sections below detail the WG’s recommendations for selection of the ICA methodology and further refinements. Where possible, recommendations are mapped to the specific section in the ACR.

The WG recommendations are in these categories:1. Use cases of ICA2. Development of common IOU methodology3. Schedule and timelines4. Review of cost estimates5. Frequency of updates6. Presentation of values

6 See “Next Steps” section

6


Also heading way too long.. I recognize basically all sections are “Section 3”. Will break this up somehow.


Please use a darker heading color. This is hard to read when printed in black and white.


Added additional language


Needs further clarification due to sentence structure/grammar. Is it saying the ICA WG will have a prioritized list of long-term refinements by September 2017?


Laura – I recognize we need to use this term since it was in the ACR to refer to that timeframe, but of course we also talked about some “long, long” term issues. At the end of the drafting process you may want to do a “find” to make sure that “long-term” is being used according to this definition throughout.


For the purposes of the record, I think it is important to make clear that the WG made its decision based on information that is not available in those reports. Not meant as a ding on the reports, but there was a lot of additional information shared in our meetings that isn’t currently documented in those reports.


If we want to put the dates, then I would ask that it indicates that SCE provided this by end of December 2016.


Will leave as placeholder now, though currently SDG&E’s maps are not available.


Lets make sure this is true, I am not clear if all the maps and data have even been made available yet.




7. Standardization of methodology8. ACR requirements9. Short-term activities10. Long-term refinement activities11. Modifications to scope and schedule12. Additional cost recovery13. Recommendation summary table

These recommendations are based on WG discussion of IOU Demo A reports from May 2016 to March 2017, and focus only on areas of refinement rather than providing a full summary of Demo A projects. Areas where this WG report does not comment on methodology outlined in final IOU reports is considered as support for, or non-opposition to, methodological choices made for Demo A.

The WG recognizes that this report provides a key resource for the Commission to make a Proposed Decision on the final common methodology to be deployed system-wide across all three IOUs. This full system implementation requires significant effort and resources from the IOUs. The IOUs have provided the following cost estimates for various scenarios of system-wide ICA implementation, taking into account modeling software and hardware, staff resources, and additional tests to further refine methodology. Section 3.4 below outlines the results of that discussion. As further explained in that section, the results of the cost discussion are incomplete; however, the WG has made its best effort to provide concrete recommendations for moving forward in absence of complete information.7

[3.1] Use Cases of ICAThe WG agreed to identify the specific uses of ICA and make recommendations on ICA based on these concrete use cases, to the full extent possible. The WG expects that methodological considerations regarding frequency of updates, hourly load profiles, the basic methodology (streamlined vs. iterative), and other modeling options, may change based on the intended use of ICA.

At a high level, the WG has so far identified two uses of ICA:

[1.] Inform and expedite improve the Rule 21 interconnection process. In the interconnection use case, ICA information may potentially be used to update Rule 21 interconnection procedures and expedite improve the interconnection processes. The results can also be used to better inform proper siting of projects prior to entering the interconnection process. The WG recognizes that the interconnection process changes must be made via an appropriate Rule 21 proceeding.

1.[2.] Inform and identify DER growth constraints in the planning process. In the planning use case, the ICA information may be used as an input into system planning processes to identify when and where capacity upgrades are needed on the distribution system as a result of various DER growth scenarios.

7 These costs were based on the proposed recommendations put forth by non-IOU stakeholders to the IOUs on 30 January 2017.

7


Thank you!


Looks good to me


Proposed language based on discussion from webinar, looking forward to comments. Leaving one summary here and the rest of the discussion is in Section 3.4


Yep moved to section 3.4 as its own separate discussion

Curt Volkmann, 03/03/17,

I suggest moving this section on costs for the various scenarios later in the report, perhaps to section 3.7.6 or 3.9.




The WG report outlines methodological refinements to enable the use of ICA within the interconnection process as determined by a future Rule 21 proceeding, and lays out considerations for the planning use case with a goal of developing methodology recommendations for use within the planning context.

These two use cases of ICA are described in further detail below:

[1.] Informing interconnection siting decisions and facilitating a more automated and transparent an expedited improve the interconnection process

The CPUC final DRP guidance document calls for the “dramatic” streamlining of interconnection as one of the key purposes of the DRP.8 ICA results can also help customers and third parties design DER systems that do not exceed hosting capacity by providing accurate information about the amount of DER capacity that can be interconnected at a specific location without significant distribution system upgrades. The WG expects that future Rule 21 proceedings will closely coordinate with the development of ICA to implement the recommendation in this report as deemed applicable. Thus, the WG proposes that the Commission adopt an interconnection use case and that it include the following considerations pending discussion under a still-to-be opened Rule 21 proceeding or equivalent. Utilities also specifically point out a need to coordinate the application of ICA with the need to install the required interconnection facilities. regards to timing, configuration, and equipment used for interconnection. The WG identifies the following features as the core components of the interconnection use casefuture Rule 21 proceeding should consider for modification to Rule 21 the following:

[1.] Developers should be able to submit a Rule 21 Fast Track application for DER interconnection up to the identified ICA value at the proposed point of interconnection, based on ICA figures shown on the map, changes in queue DER since last map update and in the underlying data, and be able to pass those screens representing criteria the ICA has evaluated if ICA values accounted for queued generation since last map update. Rule 21 proceeding should identify processes and procedures which are required to support safety and reliability while maximizing the ICA values to improve the interconnection process, including but not limited to procedures associated with the evaluation procedures to account for frequency of updates, queued generation, ICA value at the time of interconnection, and resolution of screens not addressed by current ICA methodology.

[2.] The ICA values identified at a point of interconnection are expected to replace and/or supplement the size limitations in the fast track eligibility criteria and will be able to address the technical screens in the Rule 21 Fast Track process which are part of the ICA methodology. that currently rely on broad assumptions that can be better addressed through the site-specific analysis contained in the ICA. These include screens F (Short circuit current contribution), M (aggregate generation less or equal to 15% of the line section peak load), G (short circuit interrupting

8 “Final Guidance Assigned Commissioner Ruling on Distribution Resource Plans. http://www.cpuc.ca.gov/WorkArea/DownloadAsset.aspx?id=5108

8


I blended the following two suggestions:Based on ICA figures shown on the map and in the underlying data, and be able to pass those screens representing criteria the ICA has evaluated. (IREC)Based on map and changes in queue DER since last map updated, and be able to pass those screens the ICA has evaluated in ICA values accounted for queued generation since last map update. (IOUs)


I disagree with this framing, we are not recommending this for future consideration in the Rule 21 process, we are recommending that the Commission adopt this as the interconnection use case for the ICA. Whether and how this is executed in the Rule 21 process will require further discussion, but this waters down our recommendation about what we are seeking to achieve with the ICA.


Question from stakeholders: What does this mean?? IREC: I don’t know where this originated, but I think it is captured in the comment above about the “pending discussion” in a Rule 21 proceeding? Suggest striking if you do not get an understandable clarification from the utilities.


Modified


What does this mean??


Comments reflect discussion on how to describe this use case, using the words “dramatic streamlining,” to “expedited”, etc.Multiple comments suggest using “streamlined” may be confusing to non-WG members (easily confused with “streamlined methodology”).Another comment requests we use “dramatic streamlining” based on Final DRP Guidance doc.IREC: As noted above, I recommend: “to facilitate a more automated and transparent interconnection process” Though, note that the term apparently used in the Guidance document was “streamlining” so maybe we should just stick with that?




capability), O (power quality and voltage fluctuation) and N (penetration test). With few exceptions, interconnection customers should be able to use the ICA value at their point of interconnection to know whether a proposed project will pass these screens in the Fast Track process. In the near term there will be additional screens that still need to be evaluated due to data not currently analyzed in the ICA.

1.[3.] Rule 21 proceeding should develop a process to incorporate future enhancements to ICA, which are developed in the DRP proceeding. These future enhancements would potentially address other screens such as screen L (transmission dependency/stability test) and screen P (safety and reliability) and evaluation of single-phase lines and other advanced functions, which are pending additional information, modeling, and study through ICA long-term refinements.

[4.] Rule 21 proceeding should incorporate a process for implementing future ICA methodologies which have been designed to enable projects toidentify additional criteria or Fast Track screens that can pass other screens within the Rule 21 fast track processbe addressed through use of ICA.

[5.] The utilization of the published ICA values for interconnection review. The published ICA value used for the interconnection review should be the same ICA value shown on the online maps and in the underlying data, accounting for discrepancies which may occur due to queue changes and due to map frequency of updates.

[6.] The ICA shall be updated frequently enough to allow for aan dramatically faster improved interconnection process for projects that are proposed size below the ICA value at their point of interconnection, taking in to account changes in the queue between monthly updates. At a minimum, the ICA should be current system-wide on a weekly basis and the maps should thereby reflect the updated values weekly. This would best be portrayed as the minimum and maximum load representative of each hour of the day in each month, resulting in 576 data points for each circuit segment.

[7.] The ICA should provide monthly and hourly data about hosting capacity limitations that enables a developer to design a system that takes full advantage of the available hosting capacity at their proposed point of interconnection. The use of this information in the interconnection process will require verification that the proposed operational profile address the ICA hourly limitations. It may also require some additional communication and operational visibility be provided to the utility. , contingent upon verification and increased communication and visibility to ensure operational profile of these projects abide by ICA hourly limitations. This would best be portrayed as the minimum and maximum load representative of each hour of the day in each month, resulting in 57696 data points for 576 hours for each circuit segment. As Rule 21 refinements are made, and greater resolution is provided on the cost of a more data intensive ICA (i.e., more hours analyzed), a full 8760 hours of data may be needed and justified..

[8.] Rule 21 proceeding should identify processes and procedures which are required to insure safety and reliability while maximizing the ICA values to expedite the

9


Not sure what this comments means – what does it recommend and what are the methodologies and cost implication of such proposal.


Tam Hunt:This is NOT a step forward. We had non-binding and non-actionable interconnection information in online maps 5 years ago. The ONLY way that the ICA information in the maps will be a significant step forward – let alone a “dramatic” step forward – is if the ICA process replaces IN TOTO the Fast Track screens. So for that to happen we need to have the ICA include all relevant screens.


Consensus? Discussion after considering cost estimates? IREC: I moved this up since I think it belongs better with the item above. More importantly, however, I changed the frequency from monthly to weekly. For an explanation of my thinking (and I hope the thinking of the other stakeholders in our subgroup) see the full discussion I added in the proposed cost estimates section.


This is an attempt to clarify what I think the utilities are caveating here.


Tam Hunt:This is NOT a step forward. We had non-binding and non-actionable interconnection information in online maps 5 years ago. The ONLY way that the ICA information in the maps will be a significant step forward – let alone a “dramatic” step forward – is if the ICA process replaces IN TOTO the Fast Track screens. So for that to happen we need to have the ICA include all relevant screens.


Need discussion


Nery – ended up modifying sentence below so let me know if that works


Two edits here that are getting to same point. IREC: Rule 21 proceeding should incorporate a process for inclusion of future ICA methodologies which may identify additional criteria or Fast Track screens that can be addressed through use of ICA.IOUs: Rule 21 proceeding should incorporate a process for implementing future ICA methodologies which have been designed to enable projects to pass other screens within the Rule 21 fast track process.


I am not clear how this is different from item 3 as written now?


I am not sure that is part of a Rule 21 proceeding. The Rule 21 proceeding is to implement findings in the ICA process not to provide direction as to how modify the ICA study


Reworded such as Rule 21 proceeding implements the developments under DRP ICA. Rule 21 cannot become an ICA working group.




interconnection process. , including but not limited to procedures associated with the frequency of updated and resolution of screens not part of ICA..

[9.] The iterative method is based on addedaddingedadded a fixed incremental level of DER in each grid location until an ICA violation is triggered. In Demo A, this incremental level was _500?__ kW. If this increment is used going forward, the published ICA value for any location will only be available in 500 kW steps, and ICA will provide minimal guidance regarding interconnection of small scale DER such as residential roof top solar. A smaller increment could add value to the ICA, but would increase processing time. The incremental DER value is an additional methodological detail to be considered once the IOUs have provide cost data on processing

[2.] Informing the Distribution Planning Process and Decision Making

The WG determined that there is a role for a planning use case for the ICA, as it may be possible is expected that the ICA can help determine and guide where and when future integration capacity may be needed. is a limitation among other possible planning uses. The WG envisions that ICA results may also guide sourcing and procurement of DER solutions with additional locational granularity in the future. The three IOUs all propose to use the streamlined methodology in the planning context, as the iterative methodology creates a large amount of data, and requires considerable resources to conduct multiple scenario analyses. However, many components of this use case remain undefined, due to multiple ongoing efforts in other CPUC proceedings that will inform how ICA will be used in system planning, as well as the need for further clarity into the utility annual planning process itself. Further, the multiple ways ICA may be incorporated into planning (from guiding grid modernization investments, to how DERs may be evaluated as solutions in the Integrated Resource Planning process (IRP) are quite variable in the level of detail (e.g., granular hourly profiles, frequency of updates, etc.) they require from the ICA methodology. Because many open questions remain about the precise definition of the planning use case, the WG was not able to make specific recommendations regarding the appropriate methodology (or the details of that methodology) that would ultimately serve this use case best. Finally, the WG determined that the need to incorporate ICA in planning, while highly important, is less immediate when compared to the use of ICA in expediting the interconnection of DERs through Rule 21 modifications.

Thus, the WG proposes to further define the planning use case as a key high-priority long-term refinement issue beginning March 15, and outlines several considerations for the planning use case going forward:

[1.] Further refinement of the planning use case will allow the WG to form a specific list of uses of ICA in planning, evaluate the methodological needs for each use case, and determine whether the iterative or streamlined method may better serve that use case, and define what, if any, changes to these methodologies may be necessary to best serve the use case..

10


Rather than just a choice between iterative and streamlined, I see this also as a discussion of what specific features of those methodologies might need to be refined. For example, the group made a number of methodology changes to the iterative method for the interconnection use case, the same may be true for planning.


Should this just be “planning use case”


The IOUs do not agree that it is appropriate for the WG to be recommendations that this prescriptive on the methodology. In most cases the IOUs an increment lower then 500KW but the IOUs need flexibility to select an appropriate increment based on the system complexity.


Reducing granularity down to the KW level would really slow down the ICA process. Additionally, this would only be necessary to the extent the ICA at a node is zero where the first iteration at 200KW would violate the criteria.

Tom Russell, 03/05/17,

This proposal is unneccesary as the increments used in the analysis will be dictated by the efficiency of the analysis and could vary circuit by circuit in order to get the most efficient and granular results.


This doesn’t belong here as written, but it does require discussion if it is true. ORA sent a clarification question to the IOUs but I do not believe an answer has been provided. If it is true that the 500 kW increment is used, I think we need to craft a recommendation about steps forward. For the use case discussion here, it would probably need to be two parts: 1. It is understood that the ICA will only be provided in 500 kW increments, and thus projects within the 500 kW range of the ICA will need to go through the traditional Rule 21 process to obtain accurate results for their project size. 2. The ICA should be refined to be run in smaller increments (ideally 10 kw?) in future iterations. We probably want to add something in the cost estimate section on this as well if it is true.


I thought they added increments of 50 kW, not 500. IOUs, please confirm. We need to know the implications on cost and computing time of moving to smaller increments, which will be important as the ICA is expanded to include single-phase line sections.


From ORA – I kept here but open to suggestions on where it fits best (alternatively Section 3.2.3?)


This was a good catch. At the very least the tool should be capable of 30kW increments, as only projects below 30kW are eligible for a standard NEM interconnection agremeent


SCE agrees with removal of this section

Baranowski, John, 03/05/17,

This whole section needs to be removed. For SDGE, we started at 500 until we found a violation, and then increased the granularity to home in on the final IC value.


Combined with #1




2. Some of the steps the IOUs will take to implement the first system-wide rollout of ICA for the interconnection, use case will also eventually benefit the deployment of ICA for the planning use case.

[3.] Achieving the ICA values for these identified uses may require a blended approach (using aspects of both iterative and streamlined methodology) based on future discussion on planning use cases. Refinement conversations may continue to consider the streamlined methodology. The WG appreciates and understands the benefits that employing a streamlined method offers regarding computational resources, and looks forward to better evaluating its application to the planning use case in further WG meetings.

The WG requests further guidance from the CPUC on uses of ICA within the planning context, and the role the WG is expected to play in developing uses that may be included in other proceedings or DRP tracks. These concepts may need to be discussed and refined in Track 3 of the DRP proceeding. To date, some members of the WG have suggested the following discussion items, though these are not met with consensus by the entire WG:

Non-consensus recommendations: While there is not necessarily outright opposition to these suggestions, some WG stakeholders understand that these recommendations must be further discussed and developed (potentially in Track 3) before they are implemented.

a. The scale, pace and prioritization of ratepayer funded grid modernization investments may be guided by projected ICA values. ICA may be one tool to guide and prioritize ratepayer-funded investments for grid modernization as determined by other proceedings.

b.[a.] IOUs may use the ICA to evaluate DER as potential solutions to address needs identified in the Integrated Resources Planning process.

[b.] The current system capacity revealed through the ICA may be combined with location-specific projections of DER growth (i.e., DER growth scenarios) to project system hosting capacity needs.

c. IOUs and stakeholders may consider the ICA and LNBA may in tandem to identify opportunities where additions to hosting capacity can enable DER growth and avoid more costly distribution system upgrades.

3.1[3.2] Development of Common IOU methodology

3.1.1[3.2.1] Overview

In their Demo A studies, the IOUs tested the ICA under two separate methodologies, referred to as the “iterative” and the “streamlined” methodologies. The iterative ICA method is based on iterations of successive power flow simulations at each node on the distribution system, whereas the streamlined method uses a set of equations and algorithms to evaluate power system criteria at each node on the distribution system. The iterative method parallels detailed study procedures used within the

11


drawn from the IOU’s descriptions of the methods in their Final reports.


ICA will not supersede existing planning processTomRussell: Specified “hosting capacity” to not include normal load planning.


Originally sentence was added to talk about how the streamlined use case isn’t “out of play” but we can take out if it’s confusing


Not sure what this adds.




interconnection process relying on direct simulation of resources. During implementation of Demo A projects, the IOUs tested the variance between the iterative and streamlined analyses, as well as among the three IOUs, using a reference circuit.

The IOUs presented a comparison summary of Demo A results using both methodologies, and outlined recommendations within their Demo reports on which methodology, or portions of methodology, they believe should be employed in a full system-wide rollout. The rationale behind these recommendations is based on lessons learned from the Demo projects and full system-wide implementation considerations, computational efficiency, capability of CYME/Synergi software, and costs. 9

3.1.2[3.2.2] Streamlined method

The streamlined method uses an abstraction approach, applying a set of equations and algorithms to evaluate power system criteria at each node on the distribution system. The streamlined method first performs a baseline power flow and a short-circuit simulation to acquire the initial conditions of the circuit that will be used in the streamlined calculations. These conditions can be, but are not limited to, electrical characteristics such as thermal ratings, resistance, voltages, current, fault duties, etc. The streamlined method then evaluates the full set of criteria, including thermal, voltage, protection, and safety limits independently to determine the maximum hosting capacity at a given node or component of the system. Simpler methods utilized in the streamlined methodology may not capture some of the more dynamic effects on the more complex circuits. However, the ability to utilize simpler equations and algorithms can enable faster computations on more scenarios and hours.

3.1.3[3.2.3] Iterative method

The iterative method performs iterative power flow simulations while varying the DER level at each node on the distribution system to determine the maximum amount of DER that can be installed without triggering thermal or voltage criteria violations. Fault current simulations are used for protection criteria not dependent on power flows. Due to the large number of iterations required, iterative analysis can result in longer processing times, especially when expanded to large numbers of distribution circuits. However, the use of an iterative simulation parallels what IOUs would perform as part of a detailed interconnection study, and therefore more accurate results. This technique is also expected to provide more confidence in representation of integration capacity in more complex circuit conditions.

3.1.4[3.2.4] Recommendations

The WG recommends a consistent approach be used across all three IOUs in order to facilitate future advancements and maintain consistency across the state, and in accordance with the Commission guidance ruling.

9 Reference to IOU ICA reports

12


Another nit, but shouldn’t this be “streamlining” calculators or just “calculations”? The calculations are what are doing the streamlining versus the more laborious iterative method where multiple model runs are done




After multiple meetings, the WG developed two different recommendations were developed:

1. A majority of the WG (SCE, SDG&E, and all WG stakeholders involved in the active development of this report) recommended that the iterative methodology be used for the interconnection use case (with the following refinements detailed in this report) to update the interconnection maps, expedite improve the interconnection process and be deployed in the first system wide deployment of ICA.. Within their Demo A reports, SCE and SDG&E supported the use of iterative method as appropriate means of supporting the interconnection processes, as the iterative method parallels the study procedures followed in the Rule 21 process, and considered that future changes to Rule 21 may be potentially be significantly simplified with the use of the iterative method.

[2.] PG&E disagrees and recommends the use of a “blended” approach, using both the iterative and streamlined methods within the interconnection use case. The streamlined method would be applied to an overall analysis for the whole system (and be the results shown on the map and in the underlying data),, and iterative would be utilized to analyze specific conditions within the interconnection process. This approach could result in a more cost effective implementation given that the iterative method requires more IT and engineering resources to complete.

PG&E’s Argument for the Blended Approach:

PG&E’s Demo A report explained that adopting the application based iterative and system wide streamlined recommendation would allow PG&E to more efficiently use existing resources and tool capabilities. Additionally, PG&E states that the blended approach better parallels an efficient tiered Rule 21 process that has proven to be a major success in California that promotes an efficient and accurate interconnection process. PG&E notes that there are application specific components within interconnection that can’t be considered proactively and thus can only be automated within the interconnection process and not ICA. PG&E notes that if full automation is desired then focus must shift to automating more of the interconnection process versus the proactive ICA which can only improve portions of the interconnection review.

PG&E notes that adoption of this blended approach would require fewer engineering resources for PG&E. PG&E projects that if iterative along with recommendations regarding planned projects and pre-existing conditions is required for use in the maps and in the interconnection review then it would need a new team to manage the ICA process SCE and SDG&E do not share this opinion. PG&E projects if streamlined is adopted and the iterative approach is adopted more efficiently on application basis then it is projected that the new work load can be more efficiently managed with current engineering resources.

PG&E is also undergoing existing planned work on modifications to its gateway to (1) utilize the new GIS system implemented in 2016, (2) expand the gateway to include substation models, and (3) expand its ability to include service transformers in the models. If recommendations require the incorporation of planned modifications and automated iterative across the whole system then significant additional work would be required on the gateway and could postpone work to include substation and service

13


what? This sentence doesn’t make sense. Attempted revision:PG&E projects that if it is able to deploy the streamlined method for the map and underlying data, and the iterative for the processing of interconnection applications, then the new work load can be more efficiently managed with current engineering.


I don’t know what this means, this needs to be much more specific. I have suggested adding language in response to this because I consider this to be a misleading and untrue statement at this point.


From IREC:I would find it helpful if the preceding and following comments could be clarified to make it clear whether PG&E’s desire to use a blended approach is largely driven by their own unique circumstances, or whether they would be making that recommendation either way. I also think it would be helpful for the Commission if PG&E explained why the tradeoff of not having an ICA map that matches the interconnection outcome is worth making]


From IREC: [Out of respect for PG&E I think the following section needs considerable work in order for the Commission and other parties to understand (1) what PG&E is actually proposing, and (2) why. Currently, as written, I think it would be hard for anyone to understand their position. I think it should be clear to the Commission what constraints PG&E has on being able to implement the iterative method in comparison to the other utilities. I do also think, however, that it needs to be clear that this is PG&E’s opinion.]


From ORA: ORA is not sure whether the WG should support the “blended” method, since the use case for such a method has still not been adequately defined, nor has the cost information for the need of a blended approach been identified. Essentially, having three separate methodologies (iterative, blended, and streamlined) would further complicate the process of defining one standard methodology between the utilities.IREC: I don’t think the WG is recommending the use of a blended approach, only PG&E is.




transformers. Also, if PG&E’s recommendation of application only based used of iterative is not adopted, then more engineering resources would have to be hired and trained in order to perform the regular iterative ICA analysis. Adopting the application based iterative and system wide streamlined recommendation would allow PG&E to more efficiently use existing resources and tool capabilities

The WG Argument for Use of the Iterative Approach for Mapping and Interconnection Processing:

The WG discussed application of the “blended” approach as suggested by PG&E and concluded that the approach was unsatisfactory in meeting the goal of the interconnection use case, which seeks to move towards an automated process that requires less manual review by engineers and would enable the ICA information displayed on the map to be the same as what is applied in the interconnection process. If the maps and data were derived from the streamlined method, which Demo A demonstrated is inaccurate in too many cases, then interconnection applicants would not be able to rely on this information and would be left in the situation they are currently in where getting accurate interconnection information requires a manual review by the utility. The WG considers this to be insufficient progress.

The WG appreciates that PG&E is in a different position from the other utilities with respect to the rollout of its models and software. The WG shares PG&E’s concern about how it will implement the iterative process on its system in light of the work planned on its gateway and other concerns. However, the WG believes that a consistent methodology is a fundamentally important principle, one required by the Commission in its Guidance, and is necessary to avoid a slippery slope of further diversion once rolled into the Rule 21 process. Additionally, the WG discussed that there may be reasonable ways to reduce the data intensity while utilizing more efficient computing resources to address concerns regarding computational intensity of the iterative method. PG&E could look for additional solutions in their efforts to reconcile their data using the iterative approach. In the long run, it seemed likely to the majority of the WG that the costs of the computing issues could be reasonably managed as technology and understanding of the ICA methodology advance.

Finally, the WG emphasizesstakeholders emphasizeds a desire to maintain a consistent approach across all three IOUs in order to facilitate future advancements and limit confusion across the state.

The WG also recommends that the WG and IOUs continue to evaluate the streamlined method for potential use in the planning use cases. Given that planning use cases are still being evaluated, the WG recommends that further discussion is needed to determine the appropriate ICA methodology for the planning use case and that continued discussion of the streamlined method as support to the planning use case be part of long-term refinements to ICA.

3.2[3.3] Schedule and Timelines

3.2.1[3.3.1] Timeline for implementation

14

David, 03/06/17,

This section is largely redundant with the section further below (“Establish definite timelines for future achievement of ICA milestones”We recommend merging that section into this one here for a more logical narrative flow. It’s confusing to start the conversation here, but not have the full discussion until much further down in the text.So basically, move all the text from below up here, and that section below would basically just say “this was addressed in section 3.3 above”If we don’t merge these two sections, the please do the following: delete the two bullet points in the first section and simply state “there was not consensus; please see 3.7.6 for details” (in other words, we DON”T want to have these two recommendations listed here if we don’t have all the context from the secition down below.)




Following the completion of Demo A, the IOUs plan to perform final system-wide implementation of ICA. The WG engaged in multiple discussions surrounding expediency around this implementation, given the size and complexity of this project.

Stakeholders and the IOUs have separate recommendations regarding when the IOUs should implement the ICA across their service territory. In both recommendations, the ICA methodology should include the identified short-term recommendations from the final report.

Proposal 1: Implementation within 12 months of a PUC Decision. All three IOUs (plus X stakeholders) recommend that the ICA is be implemented within 12 months of a CPUC decision on final ICA methodology.

The IOUs understand the urgency of implementing an approved ICA methodology system wide and the IOUs are committed on implementing the ICA Methodology in the most expeditious manner. The IOUs also ask the stakeholders to understand that what is being asked is a very large and complex project which has not been attempted by any utility. For reference, in Demo A, SCE performed an ICA on 82 distribution feeders and the time allowed for that was 4 months. In the system wide implementation, SCE has to implement ICA on more than 4,500 distribution feeder which exponentially higher in magnitude with significant reduction in time as compared to what was done in Demo A (Demo A: 21 circuit/month, System implementation: 375 circuit/month).

While a final decision is pending, the IOUs will continue to work on preparation activities such as preparing network models, data sources, work force plans and implementation procedures. Once the PUC issues a final decision, IOUs anticipate 12 months will be necessary for implementation.

More specific details on what IOUs work activities prior to and after the decision are outlined below (applicable to all three IOUs):

Work to commence while a decision is pending: Model creation and validation: SCE engineers to create distribution system models. Activity can

start prior to PUC Final Decision, but it is estimated to last 10-months. Preparation of data sources: Preparation of data sources such as, SCADA Historian, GIS, and

Distribution Management System is required.

Work to commence after decision (12 months): Implement ICA Methodology – SCE estimates 4 months of development once final ICA

Methodology is established. Work cannot start prior to PUC final decision as development requires all assumptions and functionality be outlined prior to start of solution design. In addition, based on Demo A work, various iterations of testing are required to stabilize code (e.g., troubleshoot bugs) to render solution production ready. Code will not be stabilized until after various distribution circuit models have been analyzed. Vendor engagement is required.

Run ICA – Perform the ICA on the distribution system models. Based on the ICA Methodology requirements (e.g., number of hours, periodicity of updates) computing resources need to be

15


I am not sure what the comment is saying. As stated in our detailed explanation, SCE is working throughout this process including the decision-waiting time to prepare us for a successful full implementation.


Brandon Smithwood:I want to make clear that I for one totally recognize and appreciate that this is a HUGE effort and that tons of great work has been done by the IOUs. The issue is making sure that we have something that is ready for a dramatically streamlined interconnection process. I am mostly concerned about anything that will create path dependence—is there a decision we make which will have long term consequences when we go to revise Rule 21? My view is if we have cost estimates on different levels of computational intensity we can make decisions based on the ICA’s functioning over the long term (i.e., not just the initial system wide roll out).


Check back. We had added justification as to why we need the 12 months after final decision.


PG&E: should I separate out your recommendation for June 2018?




configured and computing resource management systems may need to be developed. Work with vendor community is required.

Quality Assurance and Control– In support of ICA Methodology implementation activities, and to support SCE in the publication of most accurate results, quality control and quality assurance systems and processes need to be designed, developed, and implemented.

Publication of Results – Develop interfaces between ICA Results databases, mapping databases, and other data sources required by the PUC final decision. Edit map symbology to meet ICA requirements.

Separately, PG&E recommends that the ICA be implemented by June 2018, to coordinate with PG&E’s planning process (currently distribution planning analysis and engineering review occur in the January to May timeframe). PG&E notes that if adopting recommendations of PG&E to use the “streamlined” method for system wide analysis and the “iterative” method on an as requested or pre-application basis, then it is expected that less engineering resources are needed to implement this efficient approach.

IOUs strongly recommend that the appropriate time to complete full system wide implementation of ICA be 12 months following PUC final ruling. This will insure that IOUs can implement the appropriate methodology without the risk of losing valuable engineering work if decision is different from the anticipated. Additionally, IOUs will continue to prepare those elements such as preparing network models, data sources, work force plans and implementation procedures that are needed for full implementation while a decision is provided.

Proposal 2: Implementation within 12 months of ICA WG Final report. Other stakeholders recommend that the IOUs begin the implementation process following the publishing of the ICA Final WG report, and finish implementation within 12 months of final report submission.

After review/discussion of this section, still split recommendation of 12 months from report vs. 12 months from Commission decision vs. PG&E separate recommendation?

[3.3.2] Recommended regulatory process

Further, the WG recommends that the Commission establish two processes to incorporate modifications to the ICA both as part of the implementation of ICA system wide on its first rollout and as future enhancements are added to the methodology. These processes should balance the need for flexibility in implementation and appropriate CPUC practices for review:

1. As the utilities continue to refine and enhance the ICA methodology through long term enhancements to ICA and based on future advanced studies, such as inclusion of smart inverters, single phase line sections and transmission impacts, it is requested that the Commission establish a process to allow the ICA WG to collaborate and determine how enhancements to the methodology are to be deployed system wide. The WG views the ICA methodology as one which will continue to evolve in an expedited and effective manner. This process should provide flexibility to phase in refinements within

16


The WG recommends the CPUC establish a process that allows the IOUS expeditiously inform stakeholders and implement the change in plans. Specifically, WG recommends that the CPUC establish a process by which IOUs could modify the planned scope and schedule of the ICA implementation by filing a Tier 1 Advice Letter. This process would allow changes to be formalized and visible to all parties, and the AL process provides an opportunity for stakeholders to formally respond to the modifications.


Brandon Smithwood:This is another good question related to my question above. Should the ICA be revised by rulemaking (that would be WAY too cumbersome), WG/or staff (seems too informal), revisions to the interconnection handbook (too much utility control), advice letter (maybe this fits the goldilocks standard and is “just right”)?


WG comments/feedback on report needed on “Commission guidance on what is appropriate, gives appropriate levels of flexibility and maintain consistency with CPUC guidance”


Brad Heavner:I’m wary of creating a formal WG approval process and having the CPUC rely on it. We need next steps for CPUC action in addition to flexibility to implement changes that are consistent with CPUC guidance.


IREC does not feel strongly about this, I am ok with letting the utilities have 12 months from Commission decision, but note that PG&E should be prepared to do it in less if the final decision is delayed to June for some reason.


Just like the IOUS provided details as to why we (IOUs) propose 12 months after decision, these stakeholders should provide justification and criticality for not waiting 2-3 months.


Agree, hoping one of the stakeholders can volunteer text




boundaries established by the CPUC. The WG recommends that consultation with the WG followed by a Tier 1 Advice Letter be the process adopted for approval of ICA methodology refinements.

[2.] The methodology and refinements recommended in this report are based on the best available knowledge of software and tool capabilities, costs of implementation, and complexity of the project. Further, there are several meaningful recommendations made in this report that were not required to be tested as a part of Demo A, but were discussed among the WG as part of its direction from the ACR to “improve and refine the ICA methodology.” For these recommendations, the WG engaged in discussion regarding the need for changes, and the practical feasibility of incorporation within either the initial system-wide rollout, versus establishing as longer-term goals. Given the scope and complexities of system wide implementation of ICA, the WG acknowledges that new challenges and limitation will surface that are not possible to predict at this time, but may arise during full system rollout, and recommends that the Commission establishes a process for the IOUs to modify scope and schedule of the roll out due to these unforeseen circumstances. It is recommended that these requests are brought to the CPUC Energy Division for resolution.be sought through a Tier 1 Advice Letter.. For those changes, the WG expects that IOUs will prioritize their resolution in the next iteration of ICA, and work with stakeholders on refinements that may be necessary as a result of new learning.

3.3[3.4] Review of cost estimatesPROPOSAL FROM 2ND DRAFT

Several non-IOU WG stakeholders have asked for narrower ranges in the cost estimates and clarification on which dimensions of the scenarios (i.e., frequency of updates, number of loading conditions) contribute most to the cost. Absent this additional detail, the WG is unable to provide a consensus recommendation on the preferred approach. However WG refinements consider these estimates in context when making recommendations, given the considerable variability contained within the numbers, and difficulty in attributing certain methodological refinements to a proportionate level of additional costs. Level of confidence within estimates among these six categories vary, and some are more significant than others (e.g., frequency of updates is more impactful than number of hours from a cost perspective).). All parties recognize that these numbers are estimates only. So, while the WG endeavored to weigh these cost estimates within the context of necessary granularity to meet the identified use case, it also realizes the limitations of doing so based on the existing information available for review. These considerations are particularly important with regards to Development of Common Methodology (Section 3.2), Frequency of Updates (Section 3.4) and Computational Efficiency (Section 3.7.3).

DRAFT ALTERNATE FOR CONSIDERATION

17


I have written the following section to more thoroughly explain the cost estimates, their limitations, and how the WG took them into account in its decision-making process. I think a more thorough explanation is important so the Commission understands where the uncertainty lies in some of the recommendations. I am not quite sure where this section should go, my gut is that it belongs after the recommendations are discussed, but could be modified to go here as well. I recommend deleting the two paragraphs above and replacing them with the discussion below.


Proposed language based on discussion from webinar, looking forward to comments


Correct, that is the case for SCE. Increasing frequency of updates would drive updates to other SCE systems



This is what I heard from webinar, but if there isn’t confident confirmation, we can just take out.


David, the understanding was we would be filing a Tier 1 advice letter to adopt/address significant ICA Methodology changes moving forward. Is this not the route we’ll be taking?


As written, includes discussion on potential things included in first system roll out?




After reviewing the results of the Demo A, and identifying the inaccuracies in the streamlined method results, the WG collectively turned its attention to how to best deploy the iterative approach in a manner that would achieve sufficient granularity in the calculated ICA, while also balancing the computing time and costs. There are at least three different elements to consider when evaluating how to reduce the computational burden of the iterative method: (1) the methodology itself, (2) the software/hardware it is run on, and (3) the staff time associated with running the model and any manual efforts required to maintain it. As indicated in the Final Reports, each utility reported significantly different processing times for the iterative method (note that this was not an apples-to-apples comparison as the utilities used different hardware, software, and computational efficiency measures in their Demo A results). In slides prepared for the WG meeting on January 6th, the utilities reported the following times on average per feeder: PG&E - 23 minutes, SCE - 83 minutes, and SDG&E - 1,620 minutes.

Methodology: The IOUs identified a number of factors that could be modified within the iterative methodology in order to reduce the computational burden; these included reducing the number of nodes, reducing the number of hours in the load profile, reduction of the limitation categories evaluated on strong feeders, the frequency that the analysis was run, and whether it was run system-wide or on a more “as needed” or “case-by-case” basis. Note the utilities did not all deploy each of these computational reduction strategies due to time and other factors in Demo A, which may be one factor in the difference in computational time seen in the results. The WG also identified a need to understand the computational effect of allowing voltage regulating devices to “float” instead of remaining “fixed” or “locked” in the model. Other than the reduction in nodes and limitation on categories (which the WG concluded were logical computational savings that should be implemented since they did not have a significant impact on the results), each of the other factors could affect the ultimate usability of the ICA to achieve the interconnection use case goals and the accuracy of the ICA that is ultimately calculated.

Hardware/Software: Each IOU used a different combination of software and hardware to run the Demo A results. For example, SDG&E indicated that the “streamlined simulation was performed on a server based computer, while the iterative was performed on office laptop computers.” SDG&E Demo A Final Report at 43. PG&E “used a combination of local machines and servers which relied on many parallel computing streams for the analysis.” PG&E Demo A Final Report at 143. SCE’s report did not specify the hardware used to run the models in their Final Report, but they explained to the WG that SCE utilized local servers to run the results. In addition to the differences in hardware, the use of CYME or Synergi and other related software also impacted the computational burden of Demo A.

Staff Time: An additional factor that did not get covered in as much detail in the Final Reports or WG discussion was how much staff time would be required to run and maintain the models depending upon the methodology selected. PG&E in particular indicated that running the iterative method for the interconnection use case on their system could require significant increases in engineering staff support since they are not currently able to maintain their models in an automated fashion.

Recognizing that the ultimate formula of these different factors that is selected could have a potentially significant impact on the costs associated with deploying the ICA, the WG sought cost estimates from

18


Verify, do I remember this correctly? Is there somewhere this appears in writing?




the utilities that would help illuminate which factors have the greatest effect on costs. This information was sought to assist WG members and the Commission in making an informed recommendation for how to deploy the iterative method for the interconnection use case. On January 30th, the WG members requested (see Appendix?) that the IOUs provide a base case estimate of the costs to run a plausible scenario for each of the two methodologies and then identify the cost factors associated with a set of defined sensitivities. For the iterative method, the WG asked for information on the following sensitivities: (i) Frequency of running the model; (ii) Hours (i.e. 24, 576, 8760); (iii) Movement of voltage regulating devices; (iv) Method of updating a system-wide ICA (i.e. a “case-by-case” basis or on an “on-demand” basis). The WG also asked the utilities to identify (i) what costs are one-time costs, (ii), which costs are variable but will decline over time, and (iii) which costs are variable, increasing with increased levels of computational intensity.

In response, on February 27th, the utilities provided the WG with the following table that summarized their cost estimation efforts, and subsequently provided the WG with the list of factors that went into those cost estimates.

Iterative Cost ($000) (Year 1) Cost ($000) (Beyond Year 1)

Scenario 1: 96 loading conditions, monthly updatesICA WG Iterative Methodology base case

PG&E $2,040-$3,800 PG&E $1,740-$3,050

SCE $3,300-$6,300 SCE $1,400-$2,600

SDG&E $2,200-$3,300 SDG&E $1,100-$1,700

Scenario 2: 576 loading conditions, monthly updates

PG&E $2,990 - $5,300 PG&E $2,690 - $4,550

SCE $3,800-$7,000 SCE $2,200-$3,900

SDG&E $2,400-$3,500 SDG&E $1,500-$2,200

Scenario 3: 96 loading conditions, weekly updates

PG&E $4,130-$7,100 PG&E $3,830-$6,350

SCE $4,300-$8,100 SCE $2,900-$5,200

SDG&E $3,100-$4,700 SDG&E $2,200-$3,300

Streamlined Cost ($000) (Year 1) Cost ($000) (Beyond Year 1)

Scenario 1: 8760 loading conditions, annual updatesICA WG Streamlined Methodology base case

PG&E $1,480-$3,060 PG&E $680-$1,560

SCE $2,000-$3,600 SCE $600-$1,400

SDG&E $1,700-$2,500 SDG&E $600-$900

Scenario 2: 8760 loading conditions, monthly updates

PG&E $1,630-$3,360 PG&E $830-$1,860

SCE $2,000-$3,600 SCE $1,100-$2,100

SDG&E $1,700-$2,500 SDG&E $900-$1,400

19


Include cost estimates for Scenario 4: 576 loading conditions, weekly updates


Add footnotes explaining what 96, 576, 8760 loading conditions means




Scenario 3: 8760 loading conditions, weekly updates

PG&E $1,810-$3,720 PG&E $1,160-$2,470

SCE $3,300-$5,900 SCE $1,700-$3,200

SDG&E $2,300-$3,500 SDG&E $1,500-$2,200

These cost estimates consider resources to complete tasks required for system wide rollout implementation and for continue on-going support and maintenance. The typical tasks are outline as follows:

A. Model creation and validation: typically includes 1) the creation of distribution system models by integrating data from multiple sources, including SCADA Historian, GIS, and Distribution Management System data; and 2) the validation of the distribution circuit models ensuring accurate modeling of the distribution system (i.e., validate that models reflect actual planned conditions).

B. Implement ICA methodology: typically includes 1) implementation of final ICA methodology on an enterprise-friendly system capable of handling large datasets; 2) development of databases, data structures, and processes; 3) implementation of algorithms and assumptions (e.g., pre-existing conditions); and 4) additional work with vendor community.

C. Run ICA: typically includes 1) performing ICA on distribution system models and 2) working with vendor community and software licensing. Based on methodology requirements (e.g., number of hours, frequency of updates), computing resources need to be procured and configured. In addition, based on volume of data, computing resource management systems may need to be developed. “Stop and run” of ICA to troubleshoot problems is expected, proportional to the number of scenarios/loading conditions analyzed.

D. Quality assurance and control: Once ICA is complete, the results need to be evaluated for abnormal data due to divergence or modeling issues. These data can include ICA results that fail to converge, which will require manual troubleshooting by engineers.

E. Publication of results: based on the final data attributes, volume of data, and frequency of updates, development work is required to update the mapping systems and integrate these to ICA results databases.

F. Periodic updates: software development to support Tasks 1-5 to meet periodic update requirements as mandated by final ICA methodology, including automatic identification circuitry changes requiring ICA update, and end-to-end integration of processes and data.

The WG appreciates that the utilities had limited time to prepare the estimates and that some of the cost elements are hard for them to precisely predict since they may be dependent on software vendors and other unknown factors associated with doing something for the first time. However, the WG found the cost estimates to be lacking in sufficient detail to adequately guide the decision making process. The estimates look at a limited number of scenarios without identifying the specific sensitivities associated with each factor (and only two conditions varied: the hours and frequency of updates). The estimates also provide very high ranges; in many cases the top end of the provided range is nearly double that of the low end of the range. The estimates do not identify what costs may overlap or be duplicative with services or costs that have already been identified in other forums (i.e. in distribution system planning or

20




DER integration cost estimates in the utilities’ respective general rate cases). The costs are not broken out by category so that the WG could understand what portion of the costs are associated with, say, staff time vs. server costs, etc. Finally, it is also very important to recognize that these cost estimates have not taken into account any potential cost savings associated with using the ICA to create a more efficient, and less manual, interconnection process. It is expected that over time the utility engineering and administrative time associated with the interconnection process could be reduced through the use of the ICA and those savings should be considered in assessing the costs of ICA rollout.

With these limitations in mind, the WG has the following comments about how these estimates have influenced the WG recommendations. First, the WG recognizes that the costs of running the iterative method are higher than those of the streamlined method, but concludes that those costs are warranted in order to extract actual benefit from the ICA in the interconnection use case. For DER customers to be able to reduce the costs of development it is important to have transparent ICA results that will correspond to actual interconnection decisions. Correspondingly, utility costs associated with processing interconnection results will not be meaningfully reduced if the ICA results cannot be relied upon in interconnection decision making. It will take time to fully implement and realize the cost savings associated with integrating the ICA into the interconnection process, but starting with the right foundation is important to achieving that long-term goal.

Second, while it does appear that costs associated with updating the ICA weekly are notably higher, the increased frequency is important to ultimately enabling a process whereby interconnection applicants can utilize the ICA information displayed in the maps and underlying data to accurately predict their ability to achieve an automated or semi-automated interconnection decision. The WG believes that monthly should be the very minimum frequency with which the ICA should be updated, but it is inclined to recommend that weekly updates be required from the outset. While the cost information is quite speculative at this point, the WG would like to see if the utilities could identify more efficient ways of updating the ICA on a weekly basis if truly tasked with that requirement.

Third, similar reasoning applies to the number of hours evaluated in the load profiles. One of the core improvements of ICA is moving from a process that only includes annual maximum or minimum values to a process that considers seasonal maximums and minimums. Since 96-hour data includes only two representative days per year, this is not a strong enough step toward improved granularity. The WG therefore recommends 576-hour data.

Thus, the WG recommends that the utilities be required to do an initial rollout of the ICA that aims to update any changed circuits on a weekly basis and that applies a 576 hour load profile. If the cost estimates provided by the utilities are accurate, the costs associated with initial rollout will be higher under this scenario that with other options, but the marginal increase may be something like one to four million dollars per utility which, in the big picture, is a quite modest cost (i.e. a one-time cost of a few cents per electric customer). It is the yearly maintenance costs that are of more concern, but it seems likely to the WG members that these costs are more speculative at this point and could fall over time as technology improves and internal efficiencies are identified, though the WG acknowledges this is just speculation at the moment.

21




Thus, the WG recommends that the Commission require the utilities to document their processes and the costs associated with them in a granular manner for three years. Subsequently, the Commission should utilize that information to evaluate what the yearly maintenance costs are, and are likely to be going forward. At that point the Commission can reevaluate whether the actual costs are justified based upon the applied experience and, if not justified, the frequency of the updates or the hourly profile (or other factors) could be adjusted accordingly. The Commission may also want to consider applying an overall not-to-exceed cost cap should the estimates turn out to be overly conservative.

3.4[3.5] Frequency of UpdatesThe WG recommends that ICA should be updated frequently enough to allow for a meaningful impact to interconnection process for projects that are proposed below the ICA value at their point of interconnection. To meet this goal, WG stakeholder have diverse opinions on the appropriate frequency of updates to system wide ICA values.

Some WG stakeholders believe that, at a minimum, system-wide ICA values should be updated annually and that specific ICA values be at minimum updated at least monthlyweekly to reflect new projects or other system changes above a defined threshold. Since the GIS databases of the utilities are updated weekly this recommendation corresponds with that reality. This would , to allow the ICA figure shown on the maps to provide the most accurate ICA to be used for interconnection requests. The ICA should be run system-wide as needed to reconcile local changes. Interconnection approval will be contingent upon sufficient capacity in the secondary distribution system until such time as the secondary can be included in the ICA.

SCE supports system-wide monthly updates for the initial rollout with consideration of additional functionality and higher levels of frequency of updates in subsequent iterations, such as case-by-case updates, weekly or on demand updates contingent upon cost and funding and system capabilities.

PG&E and SCE notes that these envisioned condition-based updates requested by some WG stakeholders will require significant front-end coding and development to implement properly, and may create additional costs and/or delay implementation.

As a long-term vision in future years, and not part of the ACR’s long-term refinement scope (final ICA long-term refinement report 6 months from now), some members of the WG envision that the ICA should be updated on a real-time or daily basis to the extent possible to allow the reflecting values to be used in an automated interconnection process. Future enhancement should work towards this goal, while considering issues such as the following in coordination with the Rule 21 proceeding:

1. Development of automated interconnection studies which considers specific application information that cannot be known ahead of time to be reflected in ICA. Generation queuing, commercial operation dates, and planned work/transfers can all have a unique impact on certain locations in the system and currently must be considered application-by-application with manual engineering review.

22


Recommend deletion of sentence.


What does this mean? As I read it, it says that interconnections to the secondary system will be based on capacity at the secondary system as determined by the appropriate study?


Should we list them out? SEIA supports this recommendation




2. Stricter enforcement of applicant timelines and milestone provisions to prevent the risk of individuals claiming queue positions via speculative process.

3. Costs associated with the work needed to develop necessary tools and procedures.

3.5[3.6] Presentation of ICA valuesThe WG recommends that the ICA information be presented in both online maps and downloadable data formats. The ICA information to be used in the maps and to be downloadable is based on the (1) the unconstrained operation ICA value for generation (Technology-Agnostic ICA value), (2) the unconstrained operation ICA value for load (Technology-Agnostic ICA value), and (3) ICA value using a typical fixed PV production shape. The WG will provide a review of existing assumptions IOUs have used and, as part of the ICA WG’s long term refinements, develop a standard PV generation profile to be used within the online map in time to be used in the first system-wide rollout of ICA. The profile will be sufficiently conservative to be relied upon for interconnection approval, and will include monthly variation in solar production. In addition, the IOUs developed an offline ICA Calculator that can be used to help determine ICA values at specific locations for user-defined DER profiles. Users shall be able to may “toggle” maps to make maps specific to certain technologies. .

The ICA value used for the interconnection review should be the same ICA value shown on the online maps – as noted above, at a minimum, the ICA should be current system-wide on at least a monthly weekly basis and the maps should thereby reflect the updated values at least monthly. thus, the ICA maps and underlying data should be updated with the same frequency as the ICA itself (see above for further discussion of the WG recommendation on frequency of updates). Further modifications and procedures in future modifications in the Rule 21 process should take this into account.

3.6[3.7] ACR Requirements

3.6.1[3.7.1] Modeling and extracting power system data

The IOUs used either LoadSEER or an equivalent load forecasting analysis tool to develop load profiles at the feeder, substation, and system levels. In Demo A, IOUs aligned load allocation methodology with current interconnection practices, and further detailed how weather assumptions were incorporated through separate written responses10.

Stakeholders of the WG posed questions on assumptions used in load forecasting, including questions on inclusion of weather conditions (e.g., temperature, irradiance, wind speed, concurrent with each hour of the load forecast). Because load forecasts are significant factors in forecasting grid conditions and which can influence ICA values, the WG recommends that the findings and recommendations from the CPUC workshop from Track 3, sub-track 1 on Load and DER forecasting, as well as all findings from this DRP sub-track, be incorporated as appropriate into the ICA methodology. Within the ICA long-term

10 http://drpwg.org/wp-content/uploads/2016/07/WG-Recs-and-Questions-SCE-PGE-SDGE.docx

23


My understanding is that a number of us stakeholders are going to recommend 576 weekly, so I’m scrubbing “monthly” for consistency in anticipation of language being added to that effect.


I still don’t think we should settle for monthly since as far as I can tell that is an arbitrary frequency.


This was not part of the agreement when we agreed on the map specifications


Comment from Tom Roberts ORAPG&E’s map allows for users to toggle between different types of DERs (uniform generation, uniform load, and solar PV ), SCE does not include this function, [SDG&E?]. There should be consistency across the utilities’ maps, allowing for users to choose among these three profiles in order to easily see integration capacity at various line segments.


Agree with Roger. We never agreed on toggle functionality.


Is this defined somewhere, I am not fully sure I know what the “unconstrained operation means”? Does this mean the generator operates unconstrained vs. having operational limits in its Interconnection agreement?Should (3) also have the “unconstrained operation”??




refinement period, some members of the WG would like to further examine underlying weather assumptions.

The WG additionally provides the following considerations, to help inform the Track 3 process:- Stakeholders of the WG request additional transparency regarding underlying weather

assumptions from which IOU high and low load hours are derived. Understanding the conditions underlying load forecasts is important if developers are meant to model DER performance to ensure hosting capacity limits are not violated.

- Currently, there is divergence among the methodology employed by the three IOUs. Stakeholders of the WG would like to further understand reasons for methodological divergence.

- Within PG&E and SDG&E’s methodology, some stakeholders would like to further understand whether the synthetic days created are sufficiently reflective of real conditions that would be experienced on the distribution system.

3.6.2[3.7.2] Power system criteria methodology

ICA results are dependent on the most limiting power system criteria. The four criteria used for Demo A are:

[1.] Thermal criteria: amount of additional load and or generation that can be placed on the distribution feeder without exceeding equipment thermal ratings

1.[2.] Power quality/voltage criteria: steady state voltage violations and voltage fluctuation calculated based on system voltage, impedances and DER power factor. Violations outside of Electric Rule 2 and voltage fluctuation of up to 3% is part of system design criteria for all three utilities.

2.[3.] Protection criteria: amount of fault current at various protective devices factoring in contributions from DER.

3.[4.] Safety/reliability criteria: operational flexibility that accounts for reverse power flow issues when DER/DG is generating into abnormal circuit operating scenarios. Other limitations supporting the safe and reliable operation of the distribution system apply.

The WG developed recommendations regarding the input assumptions for the power system criterion. To the extent possible, the WG identified where methodological changes may apply to specific use cases.

[3.7.3] Power quality/voltage criteriaVoltage regulation

The IOUs take various approaches to how they treat voltage regulating devices within the iterative methodology. Devices may be “locked”, meaning that these voltage regulating devices do not adjust from one simulation to the next simulation in the ICA, or the devices can be “unlocked”, meaning that these voltage devices adjust to maximize voltage profile from one simulation to the next. In the field the

24


What does this mean? Examples?


Thermal overloads due to new configurationHigh or low voltage issues due to new configurationI am not sure this is what they mean


What does this mean? Provide more details.




voltage regulating devices are not locked, thus, by locking them in the model the calculated ICA will not accurately reflect field conditions. This would generally result in a more conservative ICA figure. Currently, CYME software (used by PG&E and SCE) does not have the capability for “unlocked” operations allowing voltage control devices to adjust during ICA iterations (referred to as “float”), while Synergi (used by SDG&E) does have that capability. Through WG meetings, the IOUs explained that the CYME module used for Demo A locked voltage devices to better allow for modeling convergence. Although allowing devices to float more closely models real-world conditions and results in a higher ICA, it adds to modeling complexity which increases divergence and runtime.

The WG is in consensus recommendation that voltage regulating devices should be “unlocked” within the iterative methodology, but are not in consensus with regards to timing of implementation.

- PG&E, SCE, and SDG&E recommend that for the first system-wide rollout, voltage regulating devices may be operated as applied in Demo A for each IOU (i.e. locked for SCE and PG&E, but allowed to float for SDG&E); The IOUs will work with software vendors to encourage the inclusion of an optional function to “unlock” the voltage regulating devices into the ICA modules, using a set of operational assumptions to be developed by the WG. As this requires action and commitment from vendors, assessment of impacts on runtime and analysis of ICA convergence (i.e., successful completion), this function should not be required for the first system-wide rollout but rather on subsequent rollouts when the function has been added to the power flow tools. The WG should continue to evaluate the value of not locking down the voltage regulator.

- Other WG stakeholders recommend that IOUs work with software vendors to encourage its inclusion into the first system-wide rollout, given that one software vendors have has already shown the capability to do so. If the software vendors are unable to achieve this functionality in time for the first rollout then it can be delayed, but the stakeholders would like to first see if this can be achieved before deferring the option further.

The WG is open to continued discussion on the number of iterations of adjustment that are appropriate to determine the most accurate ICA value in an efficient manner. The effect of unlocking the voltage regulating devices was not included in the cost estimates provided by the utilities, though it is believed that SDG&E’s estimates included that capability.

3.6.3[3.7.4] Safety/reliability, or “operational flexibility”

Demo A required two power flow methodologies scenarios for compliance with the ACR ruling which states that:

The demonstration is to employ two different methodologies of calculating the ICA values using:a) A scenario which limits power flow analysis to ensure power does not flow towards the

transmission system beyond the distribution substation bus;

b) A scenario which determines the technical maximum amount of interconnected DERs that the system is capable of accommodating irrespective of power flow direction;

25


This section is much improved, thanks!


What does this mean?


Only one vendor has shown the capability to include the functionality within the ICA methodology. As discussed above, SCE will work with vendor to include such functionality, but cannot guaranteed inclusion of the functionality by first system-wide rollout.


Not in consensus on the process and timing which would allow the IOUs to enable this feature.


Can result in either lower or higher ICA so statement should be stricken


I believe this is correct, but could it also result in not-sufficiently conservative results as well?




To comply with the requirements of (a), the IOUs employed a method which prevented reverse flow of power across any SCADA-operated device oin the distribution feeders. This method ensured that no power would be sent toward the transmission system as required by (a).

To comply with (b) the IOUs removed the limitation at the SCADA devices. This method provided an ICA value irrespective of power flow direction as required by (b).

Feeders contain open ties to other feeders in a distribution planning area that allow utilities to reconfigure circuits in response to loading condition, faults, or during system maintenance. Utilities maintain adequate “operational flexibility” to restore service to as many customers as possible and as quickly as possible during those events. This creates a challenge for evaluating hosting capacity because the reach of a DER system’s impact is not only along the circuit to which it is normally connected but also to all other circuits to which is could potentially be actively connected. For example, a DER system that could impact the power quality or thermal capabilities of an adjacent feeder should be considered even if the two items are not electrically connected during normal operating conditions.

The method of calculating the requirements for (a), where the utilities applied a “no reverse power flow across SCADA devices”, also served as limitation to provide an “operational flexibility limit” as required to maintain safety and reliability. This operational limit is used to maintain the operation of the distribution system without affecting distribution system reliability. That is, this methodology is designed to allow the highest levels of DER to be connected to the distribution feeder, without a reduction on operation of the distribution system in order to ensure that any switching operation does not create safety or reliability concerns. While the WG members agree with this general principle, some WG members also note that it has not been shown that retaining 100% operational flexibility in all cases is actually necessary to avoid safety and reliability concerns.

The intent of the safety/reliability constraint is to ensure that all operational flexibility is preserved when DERs are added to the grid. The SCADA-operated devices represent points at which the grid can be reconfigured, either permanently or temporarily. Because the ability of the grid to tolerate reverse flow depends on the configuration, by prohibiting reverse flow at these points, the ICA determines the DER adoption that produces no reverse flow in any configuration.

The WG recognizes that the operational flexibility criterion as implemented and described above is based on engineering practices that allow for calculation of the operational flexibility criteria across all circuits. However, the results of Demonstration A show that operational flexibility, as currently modeled by the IOUs, is a limit to ICA that produces conservative results which ensure power quality to all customers and DER but may be overly conservative as a result. The WG recognizes that the method used to determine operational flexibility is heuristic in nature and encourages further discussion to determine non-heuristic methods to analyze operational flexibility.

The operational flexibility criterion based on no reverse power flow across SCADA-operated devices was implemented in Demo A because no other options for ensuring operational flexibility were identified

26


Copy and paste from up the page




and determined to be feasible given the current understanding of the capabilities of either the iterative or streamlined methods. The WG agrees that this was a reasonable short-term path, but believes that developing an improved approach to evaluating DER adoption limits related to operational flexibility should be an ICA development priority.

Additionally, the IOUs included in their Demo A projects a no-reverse-flow limit across voltage regulators, in some cases ,in order to prevent power quality and voltage limits violations. This is because some voltage regulators currently on the system (both field and substation) may not be designed to allow for backflow, and existing control settings may not be adequate to properly manage increased levels of DER (some controls are programed to existing system conditions). Some voltage regulators and LTCs require finite fixed settingssetting based on the load and DER connected to the voltage regulators. Thus, allowing reverse power flow on voltage regulators without verification of regulator’s capability to accept reverse power flow, or without evaluating that the voltage regulator settings, may cause power quality issues for load and DER customers.

First System Rollout Recommendations

Therefore, the WG agrees and recommends that the operational flexibility criterion based on no reverse power flow across SCADA-operated devices is a reasonable short-term solution to the preservation of operational flexibility. Therefore, the IOUs should calculate the ICA values both, with and without this constraint in the first system-wide rollout of the ICA in order to start that process without waiting for further refinement of the criterion. The WG recommends that in the first system-wide rollout of ICA results, two values beare published:

[1.] Uniform Generation ICA values as applied in Demo A with operational flexibility limitations on SCADA devices

[2.] Uniform Generation ICA values allowing reverse power flow across the SCADA devices up to the substation low-side busbar and without allowing reverse power flow to the high-side busbar across the substation transformer towards the transmission system

Publishing both values will better indicate the hosting capacity where this factor could beis mitigated or determined to be non-constraining through Supplemental Review in the Rule 21 process. It is important to note that this second value is different than the value tested in Demo A.

It is likely that the long-term refinement of the operational flexibility criterion will include differentiating between different types of SCADA-operated devices. It is therefore important that the IOUs improve their data on line devices as they clean up data in preparation for the first system-wide rollout.

Considerations for Long-Term Refinement

Many WG members place high priority on development of an improved operational flexibility value criterion as a key long-term refinement item. These WG members envision that the WG develop an improved, less conservative more practicableless heuristic approach based on engineering analysis that evaluates whether a limit on operational flexibility actually results in any safety or reliability impacts.

27


Hi Nery, I used “less heuristic” since there’s that discussion section above that discusses the use of “heuristic” as appropriate


Less conservative or less heuristic? as a more accurate/detailed analysis may not result in a less conservative IC value.


ORA (and IOUs? Need to confirm) had commented earlier that uniform generation was preferred to not show technology bias. Confirm with group.


We have all agreed on multiple occasions that a standard PV profile should be used as the ICA number. If the IOUs also want to publish a uniform generation profile that is fine. But this is not the question in this section.


Revised to reflect my understanding that it is not the case that ALL voltage regulators do not allow for backflow, I believe this is limited to older devices. I consider this important to note simply because it may become relevant for future consideration of alternate OpFlex methods.




This new approach may be enabled by an improved understanding of the ICA’s ability to evaluate a large number of scenarios and configurations or by a discussion of how the utilities study the operational flexibility impact of an interconnection application that requires such a study. This improved value is expected to replace Screen P (the Safety and Reliability Screen) within the Rule 21 process.

These WG members additionally recognize that utility or third-party commands to DER systemsone possible solution to this restriction could be that utility may in the future utilize communication means to send commands directly to DER systems or may send communication through or third-party aggregators commands to to DER systems as to mitigate the issues related to operational flexibility. with advanced inverters may be one solution to this limitation. However, that capability will only be available after the CPUC, through an appropriate stakeholder process, develops rules for contractual relationships between utilities and DER system owners. These WG members encourage the CPUC to begin that work in the IDER proceeding as soon as possible, and additionally intend to pursue alternative methodologies within the ICA.

The IOUs would also like to examine whether the operational problem may be solved in future years through the implementation of other potential solutions. Such solutions include the implementation of future DERMS, solutions which would provide high levels of visibility and control which and would mitigate the system flexibility limitation. Some WG members are also open to these types of solutions, but would like both to be considered going forward. The WG will determine a more detailed priority list of items in the beginning stages of the long-term refinement process.

Some WG members recommend that the CPUC consider the following questions about the interplay between ICA and operational flexibility:

1. If increased DER adoption has the potential to become a consideration in operational flexibility, how can we quantify the impact of the change in operational flexibility?

2. What kind of change in operational flexibility is appropriate to reach policy goals related to DER adoption?

3. Are there technical and/or policy solutions to expand ICA while still preserving operational flexibility?

[4.] Given that DERs will provide some positive impacts on reliability and resiliency, what are appropriate trade-offs with regards to operational flexibility?

.. The utilities Some WG members view anythat reduction of operation flexibility which impacts customer service reliability in favor of increasing ICA as contrary to the goals of DER implementation. Understanding these questions may require a separate research initiative or pilot project.

3.6.4[3.7.5] Circuit models

The IOUs have not historically created computer models of their substations and distribution circuits such that engineering analyses such as power flow and short-circuit analyses can be performed. PG&E models are complete but additional work to enhance the gateway to incorporate requirements set forth by WG recommendations will be needed. SDG&E modeled its distribution system as part of Demo A.

28


do you mean the utilities only? I am not sure others share their desire to point this out yet again.


A separate research initiative or pilot project will negatively impact the ability to serve DERs and customers? I don’t think that is what is meant. I think the utilities concern about the impact on customers is clearly captured and acknowledged in the questions above, but if they want to state it again it should be separated from the need for more research.


Agree, this needs should be removed or reworded.


By definition removing operational flexibility decreases reliability, not the other way around. DERs do not increase reliability of the grid due to anti-islanding functionality.


Can we combine these two paragraphs?




SCE modeled 83 of its circuits as part of Demo A, is currently modeling the balance of its system, and expects to complete this process in approximately 8 months. While the IOUs build these models using the best available data, the models and underlying data may require adjustment if power flow models do not converge on a solution during ICA analysis. In the streamlined analysis, only one power flow analysis is performed and model adjustment is only required once (except when circuits change as discussion below). With the iterative method, additional model adjustments may be required during any of the hundreds or thousands of power flow analyses performed for each circuit, as adding DER in each location has a different impactimpacts. PG&E found that significant model adjustment was required when running the iterative method in Demo A, even though it had vetted its models to perform its streamlined analysis.11

Separately, IOU distribution circuits are constantly changing due to circuit reconfigurations, new utility equipment, new or modified loads, and DER additions. IOU circuit models must be routinely updated and vetted for ICA values to be current and accurate. PG&E has a gateway tool for incorporating circuit updates into its circuit models on a weekly basis. PG&E also creates yearly planning models from a snapshot of the gateway model which contains specific modifications and planned worked on the circuits. Recommendations from the WG would require additional work to merge the planning models with the gateway models. , but these updates cannot yet be included in an iterative ICA. SCE would incorporate significant changes to new circuit models in a monthly basis and SDG&E would [John to insert SDG&E proposal].? SCE? Stakeholders expressed that ICA cannot be deployed on a system wide basis until each IOU develops a means to adequately incorporate changes in the distribution circuits and loads. Therefore, the WG recommends the IOUs’ present to the WG the ability to incorporate changes to their circuit models before a full circuit modeling takes place.

3.6.5[3.7.6] Pre-existing conditions

The WG identified a challenge whereby circuit models sometimes display violations of one or more power system criteria before the DER adoption is modeled, resulting in a hosting capacity of zero (i.e., a pre-existing condition on the circuit is responsible for the violation). A targeted DER solution may not impact the existing violation criteria, and in some cases, could even improve the existing violation criteria. However, it may be difficult to automatically determine whether adding a DER solution worsens a violation criteria or creates an entirely new violation.

To address this condition, the WG recommends that the IOUs understand that (1) ICA should be limited by pre-existing conditions when adding DER degrades the pre-existing condition and (2) that ICA should not be limited by a pre-existing condition when adding DER improves the pre-existing condition. For example, in a situation when low voltage exists in an area, adding generation may improve the low voltage condition but adding load may degrade the pre-existing conditions. In this particular example, the ICA for new generation would not be limited by the pre-existing condition but the ICA for new load (i.e. electric vehicles) would be limited by the pre-existing condition. It must be noted that in some cases, such as substations with load tap changer (LTC) control, adding generation to a low voltage pre-

11 PG&E final Demo A report. http://drpwg.org/wp-content/uploads/2016/07/R1408013-PGE-Demo-Projects-A-B-Final-Reports.pdf

29


If I understand correctly that the IOUs are not objecting to this recommendation, then I believe it should be worded as a consensus recommendation and the remaining changes in this section are to accordingly make it an affirmative recommendation. As written it is a bit confusing if this is a joint recommendation, and one the utilities are willing to do despite their caveats in the last paragraph.


Agree. No more demos. This is on us to do within the year


No more demonstrations. We have to do full system rollout now to the best of our abilities.IREC: alternately, should we just state that the WG (or at least some of it) recommends that PG&E identify a way to update their models so the first rollout may commence?


SDG&E automatically updates models daily, but these are not scrubbed for ICA purposes. SDG&E would validate those models that have changes monthly for the ICA update.


SCE would check on a monthly basis and update ICA for those circuits which had a significant change.


Might be a good idea to explain WHY and also add a timeline as to when it could be done. Also, I believe Tom Russell has indicated that the reason it will take him so much staff time is to do this. If so, then it should be stated that it still CAN be done, just not automatically?


Duplicative of previous sentence, unnecessary, and not a specific assertion that PG&E made.

TOM roberts, 03/05/17,

We need to be clear here: did PG&E actually test and determine this in Demo A, or is this extrapolated from the testing it actually performed.


Make reference to section where this is discussed




existing condition may actually further degrade the low voltage condition rather than improve the low voltage condition.

In order to implement this recommendation, the IOUs will need to create automated processes as part of the ICA implementation plan to efficiently evaluate the feeders and substations for pre-existing conditions. These processes would need to determine if any pre-existing conditions exist and to determine if adding DER would improve or degrade the detected pre-existing condition and take the necessary action to determine when ICA can be allowed or when ICA must be limited by the pre-existing condition. The IOUs expect that this process will require significant IT resources to automate and/or significant engineering resources to properly consider evaluate pre-existing conditions on a regular basis. These additional costs WERE OR WERE NOT? included in the utilities costs estimates.

3.7[3.8] Short-term activities The ACR outlines seven discrete activities for WG consultation related to Demo A (ACR Section 3.1). The IOUs consulted with the WG on each of these topics in 2016. A summary of those topics, discussions, and recommendations are included below.

3.7.1[3.8.1] ACR Section 3.1.b: Recommend methods for evaluation of hosting capacity for the following resource types: i) DER bundles or portfolios, responding to CAISO dispatch; ii) facilities using smart inverters

3.7.1.1[3.8.1.1] With regards to DER bundles or portfolios responding to CAISO dispatch

For Demo A, the IOUs explored how hourly limits can differ depending on the DER technology or portfolio, without calculating separate ICA for each DER type. Through Demo A results, the IOUs concluded that location (distance from substation), rather than temporal variance, may be a more significant driver of ICA variation. It was also determined that it would be difficult to accurately define the ICA in a meaningful way for hypothetical DER bundles, without knowing the specific operational profiles and combination of the DER in the bundle. This supports locational mapping of single values to be the more effective publication, while raw temporal profile publication will be supplemental.

The WG consistently supported the IOUs’ approach in Demo A of using The IOUs recommend continuing the use of a technology-agnostic approach in a full system-wide rollout of ICA, rather than making assumptions about CAISO dispatch, or basing the analysis on assumed characteristics of different resource typesother specific resource types. The WG is in agreement and recommends that utilities continue with use of a technology-agnostic approach to determine ICA values in the full system-wide rollout and not be required to determine ICA values based on technology specific DER bundles or portfolios.

30


We did not discuss this in terms of location vs time. Both are important, and we have always said that hour data will be provided. The question here is different.


I am not sure I understand this sentence, can someone clarify? I think maybe this might be the better way to say this, but I am not sure:“As a result of this finding, the utilities concluded that it was preferable to publish just a single technology-agnostic ICA value in the map, and to include a raw temporal profile with the downloadable data. With this information it is believed that customers can use the ICA to make siting decisions for DER bundles or portfolios.”


Define “significant”. What are the implications if this is not addressed? What % of circuits have zero HC due to pre-existing conditions?




3.7.1.2[3.8.1.2] With regards to smart inverters

The WG envisions that smart inverters can influence the ICA in that smart inverters may in certain conditions support greater hosting capacity.

Within Demo A, the IOUs did not recommend methods for evaluation of hosting capacity with regard to smart inverters. However, the IOUs did conduct analysis to start understanding the impact of smart inverters on ICA. The WG accepted this in the development of ICA as a reasonable first step. IOUs limited their Demos A study to the Smart Volt/VAR function which, when used properly, may have the ability to reduce voltage fluctuation. These capabilities were tested on a limited basis by each utility using either the streamlined method or the iterative method.

The utilities performed ICA calculations applying a limited set of smart inverter capabilities on one distribution feeder to determine how smart inverters may be able increase the integration capacity. The capabilities tested were a static volt/VAR curve (SCE) and fixed power factor (PG&E and SDG&E). The studies indicated that smart inverter may, in certain system conditions, be able to support higher levels of ICA. However, the studies performed in the Demos A with smart inverters was very limited and additional studies are required to determine how smart inverters can be used to support higher levels of ICA without causing distribution system problems.

One notable characteristic in the Demo A studies is the IOUs’ assumption of reactive power priority for sStatic volt/VAR and fixed power factor functions assuming reactive power priority. New inverter standards under pending changes in IEEE 1547 would require inverters to be sufficiently oversized to create the headroom that enables advanced functionality even when solar panels are at full production levels. A small increase in inverter size can result in a large increase in capacity to produce reactive power. It is therefore likely that assuming active power priority is an excessivelymore conservativelimiting assumptionthan actual system conditions in the future. Even with the more conservative assumption, however, the Demo A studies were helpful in evaluating a general impact of smart inverters on hosting capacity., and the smart inverter studies in Demo A are not as informative as they should be on the impact of advanced inverter functionality on hosting capacity. The WG recognizes that universal reactive power priority cannot be incorporated into ICA until standards are approved and compliant inverters are widespread, but a study to measure the impact of this will be greatly informative.

Aside from studies, on the question of incorporating smart inverters into ICA in the near term, additional methodology development and software enhancements are required. The ICA WG agrees that smart inverter functionality be included in ICA calculations when the functional methodology has been agreed and developed and tools are capable of implementing smart inverter technology in automated and efficient manner.. CYME and Synergi already contain the ability to include some advanced inverter functionality, but before the software vendors incorporate that capability into the ICA modules the WG must agree on assumptions of how smart inverters will operate.. The scope of studies will be determined with the WG will do this as part of long term enhancement to ICA, and if studies, methodologies, and tool enhancements are developed in time for inclusion to the first system wide roll

31


More like 2018. Also the methodologies have not been developedTomRussell: Agree, the functions are being finalized but the standard does not dictate how to study the functions which still needs research and development.


Brad Heavner:There is already a near-final draft of the IEEE standards. They will be adopted in 2017. Final adoption should not slow us down from developing methodology and including it in ICA as soon as it is ready on our end.


Brad Heavner:There is already a near-final draft of the IEEE standards. They will be adopted in 2017. Final adoption should not slow us down from developing methodology and including it in ICA as soon as it is ready on our end.




out, then those functions of smart inverters will be added to the first system wide roll out; otherwise, the IOUs will include the agreed upon-smart inverter functions in subsequent iterations of the ICA as studies are completed, methodologies are developed, and tools are enhanced.

The WG also identified additional studies that would inform the understanding of the impacts of smart inverters on hosting capacity, including static volt/VAR and fixed power factor functions, as inverter standards are finalized through the IEEE process and as smart inverters begin to proliferate in the market. These studies should consider two overarching questions: 1) at what point can smart inverters be expected to have an impact on increasing hosting capacity? 2) once smart inverters are implemented as common practice, how much will they impact hosting capacity?

Though CYME and Synergi currently have the capability to model advanced inverter functions, certain functionalities (e.g., fixed power factor, dynamic volt/VAR) are currently not included in ICA modules. Inclusion of additional functionalities may depend on development of assumptions and additional studies, and will require work with CYME and Synergi for incorporation into the ICA modules. SCEThe WG identified the following areas of additional evaluation: required to determine an appropriate methodology for Smart Inverter Inclusion in ICA and points out that these are very complex studies which will require significant engineering resource which will need to be prioritized based other ICA study requirements (such as Single phase, transmission impacts, etc.):

i. How the various smart inverter functions and applicable function ranges affect ICA values

1. Volt/Var[2.] FixedFix Power Factor2.[3.] Volt/Watt3.[4.] Function prioritization4.[5.] Phase II communication implications5.[6.] Phase III advanced functions implications6.[7.] Future IEEE 1547 oversizing implications if approved

Determine how the range of settings and curves that can provide maximum ICA without negatively affecting the distribution system

Determine the effects of the application of smart inverter functions to the distribution system reactive capacity and system efficiency

Additional studies have been recommended by some WG members asto much longer-term goals (2-4 years) for smart inverter inclusion, which will require additional policy discussion. . These are listed here, and may be revisited as a long-term refinement topic:

[ii.] Static volt/VAR and fixed power factor functions assuming reactive power priority. New inverter standards under pending changesreview in IEEE 1547 would require inverters to be sufficiently oversized to create the headroom that enables advanced functionality even when solar panels are at full production levels. A small increase in inverter size can result in a large increase in capacity to produce reactive power. It is therefore likely that active power priority is an excessively conservative assumption, and the smart inverter studies in Demo A are not as informative as they should be

32


This in particular doesn’t make sense and I am not sure how it should be revised.


Any WG agreement here on these areas of additional evaluation for us to say “WG”?PGE: Agreed.IREC: I don’t object to including them, but they need editing to be a bit more comprehensible. I also don’t think they are really necessary at this point, the list of additional things to be considered is quite long


More specific studies requires project resources and money to complete. These costs were not addressed in the cost table and these additional costs should be acknowledged.




on the impact of advanced inverter functionality on hosting capacity. The WG recognizes that universal reactive power priority cannot be incorporated into ICA until standards are approved and compliant inverters are widespread, but a study to measure the impact of this will be greatly informative.

[iii.] How changes in grid operations may enable greater DER penetration while remaining within steady state voltage standards.

[iv.] How ICA may potentially evaluate optimal reactive power to systematically address voltage limits. This may allow developers to locate DERs with advanced inverters at optimal locations.

[v.] How ICA may consider dynamic inverter functions, which may include settings to be changed by season, TOU period, and weekday vs. weekend, and in response to price signals and temperature forecasts. The WG should take steps towards evaluating this capability in coordination with a need for Rule 21 to include verification of operating profiles before systems can be approved based on dynamic functions.

3.7.2[3.8.2] ACR Section 3.1.c: Recommend a format for the ICA maps and downloadable data to be consistent and readable by all California stakeholders across the utilities service territories with similar data and visual aspects (Color coding, mapping tools, etc.).

The WG discussed ICA map formats in the July WG meeting. The ACR specifies requirements for how ICA results shall be available via utility maps. To reach common fundamental principles guiding the ICA map formats, the joint IOUs presented a proposal for displaying ICA results, including the structure of mapping layers (substations, circuits, line segments all visible) and which information will be viewable in map format and which will be included in the downloadable data set.

The WG agrees and recommends that the IOUs should continue to standardize to a common mapping structure and mapping functionality while using what was developed for Demo A for first system rollout, with proposed modifications. SCE recommends that each IOU map meets at the required approved functionality as identified in Demos A and that each utility be able add additional enhancements as allowed by their tools and limitation.

3.7.2.1 ICA Maps

The following attributes are currently visible across all three IOU maps for their Demo A DPAs: 1) circuit; 2) section ID; 3) voltage (kV); 4) substation; 5) system; 6) customer breakdown percentage (agriculture, commercial, industrial, residential, other); 7) existing generation (MW); 8) queued generation (MW); 9) total generation (MW); 10) ICA with uniform generation (MW); 11) ICA with uniform load (MW); 12) integration capacity of a typical/generic PV system (MW).

Currently, utilities assume that a solar system produces its maximum rated power every hour of the year and is consequently treated as uniform generation within the ICA. As hosting capacity will be measured on an hourly and seasonal basis, the hourly and seasonal profiles of DERs should be considered. The WG

33

Goldman, Brian, 03/03/17,

These criteria are not met across all three IOUs – SDG&E has still not distributed its map to the WG. PG&E is still missing a number of attributes that should be visible: substation, system, customer breakdown percentage, existing generation, queued generation, total generation.


PGE Agrees too.LW -can I say “the IOUs” or “The WG”


Given that CALSEIA proposed deleting the discussion sentences above, propose deleting this too


SCE concurs


SDG&E continues to believe these are operational concerns, and not appropriate for inclusion in the ICA




will develop assumptions for a standard PV generating profile that is sufficiently conservative to be relied upon for interconnection approval, as a long-term refinement item.

The WG identifies incorporation of single phase line sections as a high priority item for long-term refinements beginning Q1 2017, and discussed the inclusion of identifying the location of single phase line sections within the first system-wide rollout of ICA to support the interconnection use case. The WG recommends that the IOU online maps display all single phase line sections with a unique color in the first system-wide rollout. Until the ICA WG develops a methodology for inclusion of single phase line sections, the reflected ICA value will not be of the single phase line section, but rather indicate their location and point of connection to a three phase feeder.

The IOUs agree on the potential value of producing an ICA that includes single phase circuits, but additionally note that determining accurate single phase ICA would require significant investment in the development of comprehensive single phase network models. This is because the IOUs do not currently have a complete source of single phase information for their network models. The IOUs agree that the WG should continue to explore the applicability of single phase ICA values taking into account the cost to develop the single phase ICA values against the efficiencies gained from ICA values in the interconnection use case. No cost estimates have been developed on this topic at this time.

As a long-term refinement, some WG stakeholders would like to consider how the map may provide verification that available capacity has not been absorbed by another interconnection application submitted since publication of the ICA value. This factor will be reduced as utilities get closer to real-time ICA updates. Much of the coordination work will need to be done within the context of the Rule 21 proceeding.

3.7.2.2[3.8.2.1] Downloadable data sets

All IOUs make the following information available via downloadable data set from their Demo A projects: 1) Demo A final report; 2) ICA Translator; 3) load profiles; 4) customer type breakdown; 5) detailed ICA results by circuit.

The WG envisions that there may be some differences between the interconnection use case and planning use case with regards to map and dataset needs. These following recommendations should be incorporated in the first system-wide rollout for the interconnection use case only. Given the amount of data produced in calculating ICA results, the IOUs recommend limiting future downloadable data to only actionable data based on use cases determined to be deployed. Additional downloadable data should be discussed with WG to determine which data should be downloadable for system wide implementation and the associated requirements and costs.

The WG has already identified issues related to data access as an important long-term refinement item. Some non-utility WG members place a high value on providing data in machine readable formats. SCE and SDG&E have agreed to make data downloadable in kml format. PG&E objects to this due to

34


hm, this is an important point, but does it belong here? I wonder if it goes better in the section on the frequency of updates to the ICA?


what does this mean? I am not clear what they “agree” on?




cybersecurity concerns. The WG expects to consider these concerns and make a recommendation to the CPUC for a supplemental decision in time for inclusion in the full system rollout of ICA.

[3.8.3] ACR Section 3.1.d: Evaluate and recommend new methods that may improve the calculation of ICA values using computational efficiency method in order to calculate and update ICA values across all circuits in each utility’s service territory

The IOUs presented three proposed methods to improve ICA computational efficiency at the September and October WG meetings, with the purpose of reducing the number of data points needed to calculate in ICA without reducing the quality of results. These methods focus on 1) hourly reduction and mapping, 2) node filtering, and 3) criteria bounding. Each IOU employed different levels of computational efficiency methods in their demo projects. (see the Final Reports for a full discussion). The WG is in general consensus with regards to the methodology underlying these computational efficiency refinements and agrees some use is appropriate in the near-term, though as computing power and other factors change this may need to be reevaluated to seek the most precise ICA over time..

i. Hourly load profile reduction methods analyze fewer loading conditions. For example, an ICA using a 576 hourly profile (which uses minimum and maximum load days for every month, for 12 months – 24 x 2 x 12) may be efficiently reconstructed by reducing the number of hours analyzed with similar loading conditions.

ii. Node filtering methods improve efficiency by limiting the number of nodes analyzed – when nodes are within close proximity to each other with no customer loads in between, or nodes exists only for simulation purposes, those nodes have the same level of ICA due to similar levels of impedance and loading conditions.

iii. Reduction of limitation categories for feeders with a high short circuit duty. For those specific feeders, the voltage fluctuation screens and protection limitation screens do not need to be evaluated, as they will not affect the final ICA value.

SCE recommends that the computations efficiencies methods accepted by the ICA WG for utilization in Demo A be granted for implementation in the IOUs first system wide rollout. SCE also recommends and supports that discussion of computation efficiencies and new methodologies be a continuedcontinue discussion via the long-term enhancements to ICA and that modification, adjustments or additions be allowed for future ICA system wide roll-outs as deemed appropriate by the ICA WG.

WG recommendation on load profile – from stakeholder document, 576 hourly profile, weekly updates, use node filtering and reduction of limitation categories for computational efficiency

3.7.3[3.8.4] ACR Section 3.1.e: Evaluate ORA’s recommendation to require establishment of reference circuits and reference use cases for comparative analyses of Demo Project A results.

35


Don’t necessarily need this paragraph as written in full here, but does WG need to improve all methods for use, or say for ii and iii that IOUs should use them in full system roll out? IREC: I think it would be helpful for the WG to expressly “recommend” what to do with each of the computational reductions. I also think this can be a statement from the whole WG on many (node reduction and limitation categories) but maybe not all (number of hours used, all ok with 576?)I have written this out in the section on the cost estimates, I believe the stakeholder group recommends:-Node reduction-limitation categories-576 hourly profile-And weekly updates.


Makes sense


WG should not impose a “SHALL” on any of these because these are capabilities that each utility may need to use based on each network complexity.


Brandon Smithwood:Without more information on cost of different levels of computational intensity, it seems premature to use these computational efficiency measures long term. I am mostly unsure about the hourly reduction.IREC: I attempted to add Brandon’s concern in a way I hope most others will be comfortable with (really a soft point at this stage).


Make sure I have this right.




The CPUC directed the IOUs to work towards additional consistency between IOUs’ calculation methodology and assumptions, for both the iterative and streamlined approach. To ensure a common approach between IOUs, the Commission asked the IOUs to compare methodologies against reference circuits, for discussion and approval by the WG.

The IOUs used the IEEE 123 test feeder as the reference circuit for comparative analysis as it employs a public data set of power flow results. The IOUs first compared power flow results between the power system analysis tools (PG&E and SCE employ CYME, and SDG&E employs Synergi), and then within each IOU for the Demo A test feeder.

The IOU Demo A reports include a joint report component concluding that overall, the ICA results do not have significant variation across the IOUs for both the iterative and streamlined methodologies, with the slight variations attributed to how power flow models are treated between CYME and Synergi.

Another comparative assessment in IOUs Demo A projects evaluated the difference between iterative and streamlined methods. This assessment was used to determine which of the two methods would be most appropriate for the use cases and for implementation of first system wide roll out. Full exploration of these differences are detailed in the separate IOU Final Demo A Reports.

The WG recommends exploration of the utilization of more representative circuits from California feeders, and will prioritize this future testing alignment against other competing resources and cost considerations through full WG discussions, within ICA long-term refinement. This recommendation should be part of the long-term future enhancements to ICA. While SCE and SDG&E support this future exploration, SCE and SDG&E caution that there are many long-term activities and that engineering resources and costs should be factored in determining the need for these additional studies.

The CPUC Office of Ratepayer Advocates (ORA) include 12 metrics for success for evaluating ICA. ORA provided the WG with a table of these criteria on January 10, 2017, with a brief description of whether the IOUs have met the criteria. The most recent version of the table is provided below:

ORA Criteria SCE SDG&E PG&E Comments1. Accurate and meaningful results

A. Meaningful scenarios ORA: Need to verify if reverse flow at substation busbar is correctly modeled?ACR scenarios best for use cases?

36


Deleting this because of the sentence added above in tracked changes


Good with me


If phrased here, is there consensus?


Addressed below


Tom Roberts comment: I don’t think there is consensus on this – the results were different and the IOUs did not explain how the difference would be resolved going forward.IREC: From IREC’s perspective I can’t really weigh in having not yet considered the differences deeply enough.




B. Reasonable technology assumptions

ORA: Need plan to incorporate smart inverter data.

C. Accurate inputs (i.e. load and DER profiles)

Track 3 Track 3 Track 3 ORA: Track 3.

D. Reasonable tests (i.e. voltage flicker)

ORA: No concerns/alternatives from working group.

E. Reasonable test criteria (i.e. 3% flicker allowed)


F. Tests and analysis performed consistently using proven tools, or vetted methodology

ORA: Tools being developed as part of Demo A and LT refinements.

[G.] Meaningful result metrics provided in useful formats

See #5 See #5 See #5 Duplicative

2. Transparent methodology ORA: IOUs have been open to information requests.

3. Uniform process that is consistently applied

LT Item LT Item LT Item ORA: QA/QC of custom Python scripts TBD.

4. Complete coverage of service territory

ORA: Not required at this point.

5. Useful formats for results ORA: SDG&E has not provided access to results. PG&E is still missing required data.

6. Consistent with industry, state, and federal standards


7. Accommodates portfolios of DER on one feeder

ORA: Uniform Gen map, plus DER translator. Need to ensure DER translator will work independent of the map showing uniform generation or PV profile.

8. Reasonable resolution –Spatial ORA: Optimal (lower) resolution

TBD; nodal reduction proposal. –Temporal ORA: Optimal (lower) resolution

TBD; 576 vs. 24 hours.9. Easy to update based on improved and approved changes in methodology

ORA: QA/QC of custom Python scripts TBD.

10. Easy to update based on changes in inputs (loads, DER portfolio, DER penetration, circuit changes, assumptions,

ORA: Tweaks to circuit models in CYME/Synergi required for convergence are currently lost when new data from GIS and

37


Should this be red for PG&E or include a note to at least flag their concerns about being able to update the ICA using the iterative methodology.


Changed from Green to Yellow.


Same as point 1.g


Please confirm with ORA if these are still red given that we submitted results




etc.) other data sources is incorporated into power flow circuit model.

11. Consistent methodologies across large IOUs

See #3 See #3 See #3 Duplicative

12. Methodology accommodates variations in local distribution system

LegendCriteria met, OK to proceedMust be resolved before full scale deployment, but ORA believes they will be resolved by ongoing WG activity.Additional work pending as long term refinementImportant issues have not been resolved to ORA's satisfaction, and it is not certain whether they will be before full scale deployment.Delay full scale system-wide circuit modeling until resolved

Is this the right go/nogo objective? If not, what?

The legend describes how close to the IOUs are to meeting the Criteria. Green means that the IOUs have met the criteria, so it is ok to proceed with full scale circuit modeling. Yellow means that these are areas that have been identified as criteria that must be resolved before full scale deployment, but current WG activity will resolve them. longer term refinement goals. Red means that these are issues that the utilities have not been adequately resolved, and it is not certain whether they will be resolved before full scale deployment. The IOUs cannot begin full scale system-wide circuit modeling should not occur until these criteria are met. . the issue is resolved. The WG understands that not all of the requirements can or need to be met in order to begin performing the full scale circuit modeling.

However, the WG expects the IOUs to meet these criteria as the ICA is refined over time. Red means that the IOUs have not met the criteria, and the IOUs cannot begin full scale circuit modeling until these criteria are met.

3.7.4[3.8.5] ACR Section 3.1.f: Establish a method for use of Smart Meter and other customer load data to develop more localized load shapes to the extent that is not currently being done

38


Done!


From Tom Roberts:The IOUs need to add more here based on what they explained verbally at recent meetings, as from what they explain they are developing unique profiles for circuits segments based on SM data, not just allocating circuit level profiles.


Need clarification here since statements are contradictory


I think this should probably be more like a requirement from the Commission that it be resolved, rather than a delay?


Text is red inside due to track changes. Text reads – “Important issues have not been resolved to ORA's satisfaction, and it is not certain whether they will be before full scale deployment.”


For SCE, this should not be red. SCE will put systems and processes in place to prevent this from happening. SCE is in the process of mapping processes with engineering to prevent this from occurring. Should be green.PG&E – agreed, but implementing such a requirement will cost money to retool and enhance the gateway.


For SCE, this should not be red. SCE will put systems and processes in place to prevent this from happening. SCE is in the process of mapping processes with engineering to prevent this from occurring. Should be green.PG&E – agreed, but implementing such a requirement will cost money to retool and enhance the gateway.IREC: This may come down to a question about whether we have WG agreement on the recommendations. If the utilities do not agree to the recommendations of the rest of the group regarding frequency of updates, does that mean it should at least be red or yellow? If they can do it and are willing to, then yellow or green?


For SCE, this should not be red. SCE will put systems and processes in place to prevent this from happening. SCE is in the process of mapping processes with engineering to prevent this from occurring. Should be green.PG&E – agreed, but implementing such a requirement will cost money to retool and enhance the gateway.


Both Utilities need to explain more. Basic Issue is that they go through the effort to model circuit. If they update circuit, then the model needs to change. PG&E currently has a process. However, they do not have a way to get changes into model, so either the model is run without current info, or they need to input changes manually. Fundamental thing that reflects on SCE, since they have not developed this yet. Response is OK, but needs to be red, since they have not demonstrated it yet. Until they can demonstrate, is a problem. Expecting result that is based on accurate data.




In reviewing Demo A reports, WG stakeholders requested further clarification on the use of advanced metering infrastructure within ICA methodology. This application is detailed further:

SCE and PG&E aggregated smart meter measurements to their corresponding distribution transformers. That is, the loading of a distribution transformer for a certain hour is characterized by

Transformer_loading=∑_(i=0)^n▒〖Customer_i 〗where Customer_ii❑❑∑

❑

❑

❑❑

Where Custome r i represents a customer served by the transformer and nn is the number of customers served by the transformer. By performing this analysis for each hour, load shapes and patterns are generated for each transformer. These localized shapes in combination with the circuit level loading profile were utilized to allocate the feeder level forecasted loading down to the service transformer level or individual customer level. This allowed SCE to more accurately geographically allocate feeder level forecasted loading values down to specific regions on the circuit.

SDG&E brings AMI data at the time of the peak for each customer to establish the demand. Then SDG&E leverage its AMI data to develop different customer classes load profiles. Each customer class has its profile and is created per substation bus. The profile curve adding all the customers consumption on each customer class by hour for that specific class and bus. LoadSeer creates monthly profiles curves per circuit for peak and minimum day (48 points per month) using SCADA data at the breakers. These curves get imported into Synergi and the load gets allocated on the feeder using the combination of Customer class’s curves at the transformer level and Feeder profile curves at the breaker level.

It is recommended that the IOUs continue to utilize customer level load data as used in Demos A for first system wide roll out, and the WG would like to further explore reasons for divergence, as well as trade-offs between methods, as part of long-term refinement.

3.7.5[3.8.6] ACR Section3.1.g: Establish definite timelines for future achievement of ICA milestones, including frequency and process of ICA updates

Please refer to Section 3.3: Schedules and timelines for discussion on ACR Section 3.1.g.

3.8[3.9] Long-term refinement activities In December 2016, the WG filed an interim status report on long-term refinement items. This status report includes both the suggested list of topics for further refinement, as outlined in the ACR, as well as additional topics proposed by WG members. It was noted that, as the report was due before IOUs published final Demo A reports, some recommendations for long-term methodology refinement will be adjusted after full review of final demo results and incorporated into the final WG report.

39


Done!

David, 03/06/17,

Please see comment at section 3.3 above. Recommend moving this entire section up there; replace with simple statement “Please see section 3.3 above for discussion of this topic.”




3.2.a: Single phase feeders: The ACR identifies expansion of ICA methodology to single phase feeders as a long-term refinement item to begin after the submission of the final ICA WG report. In discussions to date, the IOUs have proposed to evaluate the impact of performing single-phase ICA on at least one circuit. This test evaluation would examine the capability of single phase radials to accept additional loads of DER. This test evaluation should then inform a recommended methodological approach for approaching single phase ICA over an entire distribution system.

The WG identifies incorporation of single phase line sections as a high priority item for long-term refinements beginning Q1 2017, due to its usage within the interconnection use case. To facilitate the analysis of single phase line sections once the methodology is developed, the WG recommends the following refinements to the ICA for incorporation into the first system-wide rollout:

- IOUs should further develop their gateway and circuit modeling with the understanding that single phase line sections will eventually be incorporated

- All three IOUs’ maps should visibly include all single phase line sections to enable developers to identify which three-phase circuits they are connected to without ICA or data information. Even though ICA values are not yet available for single phase lines, their locations should be shown, and it should be possible to clearly identify what three phase circuit they are connecting to.

Coordination with LNBA process The interim ICA long-term refinement report identified the need to “actively engage to determine how ICA and LNBA may influence each other or be used concurrently.”

- The WG noted that understanding where planned grid upgrades are expected, and having those upgrades indicated in the LNBA online map will also be useful to ICA stakeholders.

3.9[3.10] Additional Cost RecoveryThe WG acknowledges that continued deliberation with regards to cost impacts and cost recovery will likely occur in a separate forum. It is also acknowledged that the IOUs can continue to engage in some work related to the full system roll-out, such as data clean-up efforts, independent of a CPUC proposed decision.

Depending upon the implementation requirements adopted by the Commission, additional cost recovery may be necessary. The WG therefore recommends that CPUC adopt a process to facilitate IOU requests for additional funding to support ICA implementation. This process should occur after the utilities have provided greater insight into the reasons for variance among the cost estimates outlined above and the amount ($) of each of the constituent cost categories that the IOUs have identified as driving their overarching cost estimates for different ICA scenarios. Specifically, the WG recommends that CPUC implement a new ratesetting sub-track (“Track 1A”) with a scope narrowly focused on IOU funding requests necessary to comply with CPUC guidance for ICA implementation. Track 1A should commence immediately following the issuance of the CPUC Decision determining guidance for the ICA implementation. The Working Group Recommends the Commission adopt following schedule for Track 1A (timing refers to days following issuance of the Decision):

30 days: IOUs file funding proposals

40




45 days: Parties file comments 60 days: IOUs file reply comments 90 days: PD

3.10[3.11] Recommendation Summary TableTThrough rigorous discussion on use cases, frequency of updates, and related discussion topics, the WG recommends that the Commission bas its consideration for final decision be based on majority of consensus while considering future refinements to the ICA to account for non-consensus and other alternatives as outlined in the Ttable 1 below.

Table 1: Summary of Recommendations for Interconnection Use Case For full detail, please reference specific report sections.

Majority Consensus Recommendation: first system rollout

Non-Consensus and Alternatives

WG activity on Long-Term Refinement (6 months)

Refer to Report Section

1. Methodology Iterative PG&E: “blended” approach (see final Demo report)

2. Update frequency

Non-Consensus Monthly Non-IOU stakeholders: At least monthly, on case-by-case basisweeklySCE: no more than monthlyPG&E: dictate updates by conditions, not time frame

Use cases

3. Hourly profile 96576 24, 96, 576, 8760 <missing report section here? Or would include in a cost considerations section>

4. Voltage regulating devices

Based on Demo A implementation: SCE & PG&EPGE - Locked SDG&E – Float.

This is necessary due to limitation of existing tools (CYME) used by SCE and PG&E

SCE: The tools (CYME) which SCE is using do not currently support this option. SCE will work with CYME and tool vendors to incorporate this feature. SCE urges that if this is a requirement, SCE will likely not be able to meet the 12 months as the tools do not currently support this option

Power system criteria

41


See above


I don’t think we have majority consensus on this


See above


I don’t know what the break down of different parties is but SEIA supports weekly, 576 and it’s my understanding that other non-IOU parties will as well.


See above


Again, my understanding is that other parties in addition to SEIA are going to suggest weekly, 576


This was based on an earlier document – before then weekly had not been officially suggested as a position


How did we determine this was a majority position. It seems to me we’re divided IOU versus non-IOU.




SEIA: all utilities should be working with vendors to ensure software is able to allow load tap changers to “float” in the power flow model.

5. Operational flexibility

Publish two ICA values: 1) no reverse flow across SCADA operated devices, 2) reverse flow up to substation low voltage busbar with no export to the high side busbar towards the transmission system

Develop new methodology

Power system criteria

6. Circuit models Incorporate changes to circuit models based on utility practice

Circuit models

7. Smart inverters

Do not include in first system roll out until further studies, methodologies and modification to tools is are developed and implemented

Begin work with software vendors to determine best means of incorporating smart inverter data when methodology is developed

Begin work with software vendors to determine best means of incorporating smart inverter data when methodology is developed

Develop assumptions for smart inverter operating behavior. Begin studies on reactive power, static volt/VAR, fixed power factor – other studies TBD

3.1.b

8. Maps Publish uniform generation ICA, uniform load ICA, and a PV ICA value based on common PV shape

Develop standard PV generation profile

3.1.c

9. Computational efficiency

As approved for use in Demo A 3.1.d

10. ORA success criteria and reference circuits

Not applicable 3.1.e

11. Smart meter As used for Demo A 3.1.f12. Timelines Non-consensus Non-IOU stakeholders: 12

months from filing of WG final report SCE and SDG&E: 12 months from PUC decisionPG&E: June 2018, potentially longer based on methodology. IOUs point that without an approved methodology, automated system cannot be developed and the at

3.1.g

42


Not consistent with discussions. Adjusted to reflect more properly.


We all agreed on this no?


My understanding was that this was the position of the non-IOU parties




minimum 12 months are needed to develop such systems after final decision.

13. Scope System Wide

4 Next Steps for the ICA WGThe WG looks forward to continuous improvement and development of additional methodological components for the ICA. The WG identified a tiered list of discussion topics in 2017 in the interim ICA long-term refinement report submitted December 2016. This list of topics has been updated since, and the WG aims to create a proposed working schedule as a priority item once work on long-term refinement items begin.

Topic Rationale ACRTier 1: Higher Priority Operational flexibility criteria

Development of a non-heuristic approach to operational flexibility based on engineering analysis

Operational flexibility criteria

Smart Inverters Studies Methodology to facilitate inclusion of smart inverters into ICA at soonest possible rollout

3.1.b

Expansion to single phase feeders

Initial discussions should align with streamlined interconnection discussions, IOUs may start analysis on single phase line sections circuit on a Tier 2 timeline

3.2.a

Data access Data discussion focused on understanding IT requirements to address market sensitive information security, data sharing, and automated data analysis.

3.2.b, 3.2.d

Interactive maps Discussion focused on understanding IT requirements and benefits of increasing data directly visualized onto ICA maps.

3.2.c

Load forecast assumptions

Leverage work of CPUC DER and load forecast workshop Q1 2017

Tier 2: Lower Priority Integration of ICA into growth scenarios for decision making purposes

Refine how growth scenarios are implemented, understand how use cases for growth scenarios may impact ICA results, and make recommendations on incorporation of ICA into growth scenarios. Conversations will occur after February 2017 CPUC workshop on growth scenarios as part of Track 3 efforts.

Comparative analysis

Expansion of comparative analysis to more than one circuit and test more complicated circuits, as IOUs consider expansion of ICA to all circuits within service territories.

3.1.e

Independent Proceeding in coordination with Track 3 efforts, and following 3.2.f

43




validation of ICA comparative analysis discussion with an agreed-upon dataset and results for parties to compare and validate.The WG began consideration of validation performed by an independent professional engineer contracted by the CPUC and/or national research laboratories. This consideration will continue.

Method for reflecting the effect of potential load modifying resources on integration capacity

Begin development of methodology to include resource reliability and uncertainty factors into ICA, model resource impacts on ICA indicators, assess impacts of load-modifying resources, and include non-grid engineering analysis within ICA methodology

3.2.e

Definition of quality assurance and quality control measures

The WG will determine whether this long-term refinement issue identified in the ACR requires further discussion after reviewing the final Demo A reports begin considering

3.2.g

ICA in peak load conditions

Continue discussion of ICA that allows DERs to serve peak load conditions, while maintaining grid stability during low-load conditions

44


We have set this aside in our discussions recently, but it is very important. CALSEIA would support moving this to high priority. Nobody wants to proceed too far along the wrong track.




5 Appendix5.1 AcronymsTBD5.2 Working Group Meetings and Topics

Meeting Date Topic(s)May 12 – 1:00pm-3:00pmWebinar

Opening meeting

May 18 – 10:30am-12:00pmWebinar

Seeking input regarding 1) use of power flow analysis and 2) level of granularity

June 1- 9:00am-3:00pm In person

First discussion of demonstration implementation plan before June 16th submission

June 9 – 9:00am-3:30pmIn person

Second discussion of demonstration implementation plan before June 16th submission

July 5 – 2:00pm-4:00pmConference call

Call to discuss submission of demonstration implementation plan

July 25 – 9:00am-3:30 pmIn person

Discussion of submitted stakeholder comments on demonstration implementation plansUse cases3.1.c/3.2.c – data and maps3.1.b – portfolio analysis

August 31 – 9:00am – 4:15pmIn person

Use cases 3.1.b – smart inverters3.1.f – smart meter/customer load dataData access

September 30 – 9:00am-4:00pmIn person

3.1.e – comparative analysis3.1.b.i – portfolio analysis3.1.d – computational efficiency Data access

October 17 – 9:00 am-4:00pm In person

Demo A update3.1.d – computational efficiency3.1.f – smart inverters 3.1.e – comparative analysis3.1.b.i – DER portfolios3.2.a-g – long-term scoping discussion

November 18 – 9:00am-4:00pmIn person

Review of Working Group short term final report outlineLong-term scoping discussion of 3.2.a-g plus other topicsData

December 13 – Review of Working Group interim long-term report topics

45




webinarJanuary 6 – 9:00am – 4:00pmIn person

Review of Final IOU Demo A Reports

January 17 – 9:00am – 4:00pmIn person

Review of Final IOU Demo A Reports

January 20 – 9:00am – 4:00pmIn person

ICA Recommendations

February 2 – 2:00pm-4:00pmWebinar

ICA Recommendations and development of report

February 14- 9:00am – 1:00pmWebinar

ICA Recommendations and development of report

March 1 - Final report due

5.3 Working Group ParticipantsThe following stakeholder groups attended at least one meeting or webinar of the ICA WG:

- ABB Group - Comverge- Lawrence Berkeley National Laboratory

- Advanced Microgrid Solutions - DNV GL

- Lawrence Livermore National Labs

- Alcantar & Kahl- ECCO International Inc.

- Natural Resources Defense Council

- AMS- Energy and Environmental Economics

- Northern California Power Agency

- Artwel Electric- Electric Power Research Institute - NextEra Energy

- Bloom Energy - Energy Foundation - New Energy Advisors

- CAISO- Environmental Defense Fund - Nexant

- California Energy Storage Alliance - Gratisys Consulting

- Open Access Technology International

- California Energy Commission - Greenlining Institute

- Pacific Gas and Electric Company

- California Public Utilities Commission - Helman Analytics - PSE Healthy Energy- CPUC Office of Ratepayer Advocates - ICF International - Quanta Technology - California Solar Energy Industries Association

- Independent Energy Producers Association

- Sacramento Municipal Utilities District

- City of Burbank- Independent advocates - San Diego Gas & Electric

46




- Clean Coalition- Independent consultants

- Solar Energy Industries AssociationSEIA

- Community Choice Partners - Integral Analytics

- Shute, Mihaly & Weinberger LLP

- Community Environmental Council (Community Renewable Solutions LLC representing)

- Interstate Renewable Energy Council - Siemens

- Smart Electric Power Alliance - Kevala Analytics - SunPower

- SoCal REN- Southern California Edison - The Utility Reform Network

- SolarCity - Stem Inc. - UC Berkeley

- Solar Retina - Strategy Integration - Vote Solar

- Sunrun

869956.3

47

Documents

· Web viewmay have available to host DERs. Assigned Commissioners Ruling, November 2014. ( Pursuant