2013 PAC Form 1 vs Form EIA 861 Utah Case.docx

Docket No. 13-035-01 -- In the Matter of Rocky Mountain Power's
Proposed Utah Service Reliability Performance Baselines
April 23, 2013, Technical Conference, Room 401 Heber M. Wells Building
1. Clarification of the definition of customer count.
Customer count is fundamental for consistent, accurate reporting of reliability indices. To gain a
transparent understanding of customer count as defined and tracked in both its Customer Service andOutage Management Systems as well as in other applications the Company will provide a handoutcomparing, by rate schedule, the end of 2012 Utah frozen customer count with the Utah customercount reported by PacifiCorp in its 2012 FERC Form 1, its December 2012 EIA-826 report, the 2012general rate case filing, and the actual number of active metered customers in all Utah ElectricService Schedules as of year-end 2012.
This handout should also explain how customer count is defined in each of the above applicationsand reasons for their differences. If any non-rate schedule-associated meters are counted ascustomers in any regulatory customer count, the Commission requests the Company identify thesemeters. Also, the Company’s handout should identify by rate schedule the number of meters, andthe associated number of “customers,” where one meter may reflect more than one customer in theCompany’s analysis (i.e., see Application section of Rocky Mountain Power’s Electric ServiceSchedules 1 and 3 pertaining to master meters).
Response: Customers in the various reports are defined as follows:
FERC Form 1
Customer counts used in the FERC Form 1 are the average customer counts for the year. Simply the total number of customers each month divided by 12 months. When reported by rate schedule the number of customers reflects the number of billings (agreements). Customer counts may include multiple agreements. For example, a customer may have 5 agreements that count as separate billings but would be considered one customer. Average billing counts by rate schedule for the year provided in the FERC Form 1 are reduced by the multiple billings a customer may have to determine the number of customers reported by revenue class. Multiple billings may include billings at the same premise for area lights, Cool Keeper, separately metered and billed buildings. Multiple billings may also include billings at different premises in the same revenue class included on the same customer invoice. Customer counts with multiple billings removed are not available by rate schedule.
The Utah FERC Form 1Supplement reports the number of customers at the revenue class only.
EIA Form 826
Customer counts used in the EIA Form 826 are the total number of customers at a specific date, generally the last day of the month. Customers by revenue class are defined in the same way in the EIA Form 826 as in the FERC Form 1. The EIA Form 826 reports the number of customers at the revenue class only. Rate schedule detail is not included in the report.
The Table below compares the FERC Form 1 with the EIA Form 826
General Rate Case Filings
Customer counts used in general rate case filings are the average number of customer from both the base period and the test period. Monthly billings by rate schedule are divided by 12. Customers include non-metered accounts such as street and area lights and behind the meter customers in master metered residential buildings.Billings for Cool Keeper and Blue Sky are not included.
CADOPS Frozen Customer Count
In Service Quality reports submitted to the Commission the Company uses a Frozen Customer Count. Frozen Customer Count means the number of customers identified as of the end of the previous calendar year. While the IEEE definition identifies a customer asa metered electrical service point for which an active bill account is established at a specific location (e.g., premise) the Company’s outage management system has sufficient lag between an account becoming active to inactive or inactive to active that this feature is not separately calculated and the outage management system tallies interruption duration as the sum of all inactive and active accounts associated with a given transformer. The standard further recognizes that variations from this definition of a customer might occur and requires that specification of how the customer count is derived must be identified if it varies from this standard.Further, non-metered billings (such as area and street lights) are not included.
The Table below compares the customer count form the various reports
2. Clarification of the outage data underlying the Company’s proposed performance baselines.
The Company should provide and discuss the data underlying the graphs in Figure 1 and Figure 2 in its March 6, 2013, performance baseline proposal.
Response: In order to calculate a baseline, the Company used 365-day rolling performance data, reducing from its daily performance the effects of any approved major events, prearranged, and customer requested outages.It began accumulating daily data from 1/1/2007, as directed by DPU input. Thus, the first 365-day data point is on 1/1/2008 and continues through the review period, ending on 12/31/2012. Based on discussion with DPU, a 95% confidence interval was applied to the average performance for both SAIDI and SAIFI, which yielded 201 minutes and 1.9 events for Notification Limits. In the attached Excel worksheet the raw data is supplied.
3. Discuss the rationale for the time period used to develop the performance baselines.
Response: The Company originally proposed the use of 2002 through 2012 performance data to establish baseline performance levels, however, changes in historic measurement (the modification to IEEE 1366-2003 major events occurred on 4/1/2005) and the recognition of improvements delivered through 2006 resulted in the Division of Public Utilities recommending that the time period of history to be considered should include data no earlier than 1/1/2007.
4. Clarification of whether the proposed Performance Measures are based on a 365-day rolling average as indicated by the Company or a twelve-month rolling average as indicated by the Division.
Response: The data used to derive the average and standard deviation, and for which it calculates a 95% confidence interval, relies on the 365-day rolling history, with any one day, after 1/1/2008, represented as a single data point (accumulating the performance of the 364 days preceding it into that rolling 365-day performance level).
5. Clarification of how the Company adjusts outage data for major events, prearranged interruptions and customer requested interruptions.
Response: The Company identifies any interruption that was customer requested or pre-arranged as a normal part of its business processes. Any outage that is coded with these attributes are removed from underlying performance results against which baseline notification performance limits would be compared. The Company evaluates major events based upon a 24-hour rolling clock and when Tmed, or the 2 ½ beta major event threshold has been exceeded, begins to accrue interruptions that are associated with a major event. The event continues until the system has been restored to “before major event” interruption rates. This event is filed for Commission review. Upon approval of the filing, the Company denotes each outage as part of the major event. When reporting results, customer requested, pre-arranged and major events are excluded from underlying performance results.
6. Clarification and discussion of how the proposed “Baseline Notification” meets the Utah Administrative Code R746-313-7(1).
Response:
Utah Administrative Code R746-313-7(1) requires that ”an electric company must report deviations from the reliability performance baselines established in accordance with R746-313-4 within 60 days after the end of the month when the deviation(s) occurred.”
The mechanics of such evaluation and notification processwere considered during the development of the filed plan. At the suggestion of the DPU, the Company proposesto file a report within 60 days if the 365-day performance, at the end of each of three consecutive calendar months, exceeds the baseline notification level.This is the intention of the Company as referenced in section 1.5 of the Company’s proposed Utah Service Reliability Performance Baselines document. The rationale of allowing three consecutive calendar months before filing a notice was due to the uncertain volatility of performance from month to month. Performance that slightly edges beyond the baseline notification level on one month and then lowers the following month, however, would still be worth of semi-annual discussionas these instances may not require the same relatively rapid communication that sustained performance beyond the baseline notification level would suggest.
7. Clarification of the proposed use of “SAIDI” and “SAIFI” cause code information.
Response: In order to provide transparency into critical assumptions made by the Company in determining levels for baseline notification performance, Commission Staff advised that identification of elements that led to a calculated performance level would create a basis for the assessment. Thus, on a monthly basis, as performance is assessed over the last 365 days, the Company would compare against the cause code percentages to determine whether any single cause code led to performance beyond expected limits. If it is found that a given cause code experienced such a variation, additional analysis of the outages which led to the deviation would be performed, root causes considered, and determination made as to the ability to circumvent such an occurrence in the future. This method was intended to serve as an alternate to calculating cause code level performance over the 365 day period and applying confidence limits to each cause code, aggregating them to yield summary performance.