Appendix A 	Prorating Time Drifted Data

We are concerned about normalizing interval data when the clock in the meter does not agree with the clock in the computer reading the meter.  This phenomena is called Clock Drift.  Clock drift can be both a negative or positive value, depending upon whether the real time (at the computer) is greater than {negative drift] or less than [positive drift] than the clock in the meter.  This is illustrated below.

Normal
Computer

  Short
Interval

  Long
Interval

For each of the illustrations shown above, the actual interval for measurement is different.  We assume that the meter and the computer systems are synchronized at some time, T_0 {for example, the last meter read} and that the meter is now being read at a read time, T_r.  For each of the cases above, assume that the meter reading system reads at the same time.  The actual elapsed time is given by

 Elapsed Time  =  T_e = T_r  - T_0

The elapsed time for the shorter interval case is given by

Short Interval Elapsed Time  =  T_es = T_ms  - T_0
where T_ms is the time that the meter clock gives when the meter is read.
The elapsed time for the longer interval case is given by

Longer Interval Elapsed Time  =  T_el = T_ms  - T_0

where T_ml is the time that the meter clock gives when the meter is read.  Note that T_ms > T_0 , i.e. the meter clock is running slower therefore clocking more intervals and more elapsed time. And that T_ml < T_0, i.e., the meter clock is running faster, hence fewer intervals and a shorter elapsed time.
In each case, the internal clock in the meter is registering that the interval length is the length that is specified for the meter, namely t or 15 minutes for CA interval meters.  However, since the clock is running slower for the short interval case and faster for the long interval case, we must adjust the values such that the correct usage is obtained for each meter.  The total drift time for the clock can be calculated for each case as follows:

Total Drift Time For Short Intervals  TD_s = T_e  - T_es= T_r  - T_ms

and

Total Drift Time For Long Intervals  TD_l =  T_e  - T_el= T_r  - T_ml

Note that TD_l would be negative had we not taken the absolute value.
	The actual number of intervals for each case can be calculated using the elapsed time measured by the meter and dividing it by the preset meter interval, t or 15 minutes. Or when truncated to an integer:

Actual Number of Intervals, N =  T_e / t

Number of Short Intervals N_s =  T_es / t

Number of Long Intervals N_l =  T_el / t

We should consider at least two cases.
Case # 1 is when N = N_s = N_l , i.e. the clock drift is small enough that no additional interval is generated.  For this situation, we could elect to do nothing since for a thirty day reading schedule for 15 minute interval data, there will be about 2880 intervals and a time drift error of less than 0.04% in each interval.  The actual drift time for each interval, ignoring any fractional intervals at the end of the read period can be calculated as

DT_s = TD_s / N 

and for the long interval case,

DT_l = TD_l / N .

This result could be used in combination with the actual interval width to increase or decrease the usage in the particular interval.
Case #2 involves a situation when N  N_s and N  N_l and hence there are a fewer or greater number of intervals that expected.  Here we suggest that a procedure be adopted that distributes the measured interval values into intervals that have the correct length, namely t.  Thus we increase or decrease the interval length to correspond to actual interval length that should have been in the meter based on the drift, t + DT_l  or  t - DT_s .  Thus the interval distribution that is shown in the above figure would now have proper interval lengths in minutes.  The procedure for distribution this data is fairly straightforward.  We simply insert the real 15 minute interval grid on the actual interval grid taken from the meter and adjusted by the above technique.  Next we divide each of the obtain usage values at the corresponding 15 minute grid points.

   Incorrect
   Time

This figure shown how to allocate each of the respective values.  For example in the first interval of the correct result interval.  The usage here would equal the sum of the usage in the incorrect time interval case plus the fraction to the left of the corresponding interval in the correct zone.  For example, if the drift per interval was found to be 4 minutes for short interval case, then the time grid would be 0, 11, 22, 33, 44, 55, 66, 77, etc.  The amount taken from the second short interval would be the usage in interval 2 multiplied by 4/11 or 34%.  For the case of the third correct interval, there would be components from interval 3, 4, and 5 of the incorrect interval usage.  From the third interval, it would be 3/11 of the usage, from the forth interval is would be 100% of the usage, and from the fifth interval it would be 1/11 of the usage.  This scheme should be easy to implement.  The one caution is that additional manipulation of the usage data will be required if the interval values stored as kW for the interval, rather than kWh.  But this should not be a problem
Appendix B 	
Appendix B 	 Questions and Open Issues

Interval VEE Questions
All issues included in main body.
	
Monthly VEE Questions
1.	How do the Hi/Lo demand check rules work if demand is TOU demand?  Do you do this for each “rate” (ie, peak, off-peak, etc)?  Only the ones required for billing (if you only care about demand during the peak period)?  Answer - do for each period.
2.	For Hi/lo demand check,  what if you have historic interval data for this customer, but the customer wasn’t on a demand rate a year ago, so there’s no historical demand?  Would you try to use the historical interval data at all?  Answer - yes, but don’t have rules for it yet.
3.	In the TOU Usage check, what is meant by “the number of active peaks for the current season?  Answer - don’t know.  Doesn’t make sense and isn’t used in test.
4.	In the TOU Usage check, do you use usage or meter readings?  Usage makes more sense to me….Answer - usage.
5.	Are there different rules for demand and TOU demand and usage depending on whether the meter calculates the values or the MDMA Server calculates the values based on interval data? Answer - Discuss after Monthly VEE is done.
6.	Do we need rules for how the MDMA Server should calculate demand and TOU demand and usage based on interval data?  Answer - Discuss after monthly VEE is done.
7.	What is the recommended order to perform validation for monthly data?  Answer - do what makes sense.  Meter ID first, then time (if TOU), then …..
8.	In the Meter Read Dial Quantity Difference check, what does the “dial quantity” refer to?  The number of digits displayed?  Does it apply to electromechanical?  Does this only apply to a physical read of the meter?  Answer - dial quantity refers to the number of digits/dials on a meter.  The wording has been changed.
9.	In the Meter Read Dial Decimal Quantity Difference check, does this only apply to a physical read?  Also, does it only apply to a solid state meter?  If it applies to an electromechanical register, what does it mean?  - Answer - only applies to solid state meters.
10.	Assume the External Meter Identification check can only be done on a physical read, not a remote read via telephone, etc.  Answer - for remote read, do internal identification check.
11.	For the Usage for Inactive Meters check - who will read an “inactive” meter in the new environment?  (Assuming an inactive meter is one which is not associated with a customer.) 
12.	In the Missing Usage Meter Read estimation rule, how would you use the Load Profile to calculate the average daily usage when there is no historical data or meter reading for the customer
13.	In the Missing Demand Meter Read estimation rule, how would you use Load Profile to estimate the peak demand when there is no historical data or meter reading?
14.	In the Missing Demand Meter Read estimation rule, do we need to take into account TOU demand?
15.	Do we need rules to estimate TOU usage?  - YES
16.	Do we need validation and/or estimation rules for TOU data when the meter clock was off?  YES
17.	In the Meter Read Dial Quantity Difference check, the Meter Read Dial Decimal Quantity Difference check, and the External Meter Identification check, which “readings” are flagged if the check fails?  Just the consumption?  Or also demand, TOU, etc?

General Questions
1.	Are there any rules about having to periodically perform a physical read of the meter, even if it is normally read remotely?
2.	Is there a need for rules or guidelines regarding demand reset?  Are there any CPUC rules regarding demand reset?
3.	What kind of demand is required?  Are there any CPUC rules regarding this?  (indicating vs  cumulative vs continuous cumulative, rolling demand vs fixed demand)

Open Issues
1.	When is data considered “adjusted” vs “estimated”?.  NEEDS DISCUSSION!  The UDC’s are to provide guidelines in this area.
2.	The spike check should be revisited after a few months market experience have been obtained.

Appendix C 	 Differences from D9712048

1.	For interval data sum check, changed window to two multipliers.
2.	Eliminated use of historical power factor in kWh estimation
3.	Added threshold to spike check and kVARh check to eliminate erroneous failures for meters recording extremely low usage.

Appendix D 	 Miscellaneous Comments/Requirements

1.	MDMA is required to store raw and validated data
2.	Raw data may be stored as either pulses or consumption, but is pre-VEE
3.	UDCs are expecting to see consumption data (i.e., kWh or kVARh) in the CMEP MEPMD01 record for intervals, not pulses
4.	Historical data used in validation tests or estimation is VEE data or historical billing data, not raw data
5.	It is good practice (and will be required when supported by the CMEP MEPMD01 record) to mark each interval with one or more of the following:
•	as good if the interval passed all checks
•	as verified if the interval failed a check but the interval was manually ok’d
•	as having failed a specific test (even if data was later verified)
•	as estimated, including the estimation algorithm used.  Estimation algorithms presently identified include:  less than 2 hours, greater than 2 hours, time-drifted intervals prorated, intervals adjusted, intervals manually estimated, intervals estimated due to meter interval programmed incorrectly.
	Note that if the data is marked as good, it would not have any of the other three flags.  If the data is marked as verified, it should also have at least one flag indicating the validation test the data failed.  If the data is marked as estimated, it should include the estimation scheme used, and the data should also have at least one flag indicating which validation test the data failed.
6.	There is a requirement if data is estimated to report the estimation scheme used, but there is no field in the MEPMD01 record to report this.  The requirement is to record the estimation scheme at the interval level.  Although there is presently no way to report the estimation scheme in the MEPMD01 record, the MDMA must still record the estimation scheme used for each estimated interval.  The estimation scheme will be posted with the data when the MEPMD01 record is modified to include it.
7.	The use of historical average power factor to estimate kWh as described in the MDCS Workshop Report is no longer required.
8.	Given the order of the tests (time, pulse overflow, sum) it is possible that some data has been marked as missing or estimated by the time you do the sum check.  If the meter is a solid state meter, this almost guarantees it will fail.  To resolve this, the sum check can be done on good and valid data (excluding any estimated intervals), or on all VEE data, or on both.  The goal is to do it on both, although this is not a requirement 1/1/98.  If data fails the sum check but looks reasonable on manual inspection, the data should be marked as verified.
9.	In the high/low check, should the check be made against last year’s “billing” month?  Or against the data from last year for the actual dates in this year’s billing month?  (Since we have interval data, it can be done either way…)  Answer: initially, for most accounts the historical data will be usage, not interval.  In this case, the comparison must be done based on billing month.  When interval data is available, the check may be done either way - against last year’s billing period that has the most overlap to the current billing period, or against the specific days.  For example, if my current billing period is from 4/2/98 to 5/5/98, and last year’s billing month was from 4/4/97 to 5/7/97, the high low check could either be done based on last year’s billing period (4/4/97 - 5/7/97), or on the exact days (4/2/97 to 5/5/97).
10.	In the CMEP protocol, if you are providing raw data, missing intervals are marked with a protocol text of N.
11.	For the sum check, the wording in the CPUC ruling states “If the difference is greater than one meter multiplier, the data needs to be verified by the MDMA. If the data comes back the same, the data should be flagged as verified.”  This does not mean that if you re-read the meter and get the same data, the data passes the sum check.  See details in section on sum check.
12.	In the high/low average check - what if you have performed all the tests, including a physical meter inspection and test, and no problem is found with the meter?  Answer: flag the data as verified.
13.	Historical data used for checks and estimations should be from the same customer and the same site as the data being checked or estimated.  A meter changeout does not affect this - ie, if a meter was changed out, historical data from the previous meter at that same site may be used provided the customer hasn’t changed.  Note that there are details associated with this topic that still need to be discussed and finalized.

Appendix A Prorating Time Drifted Data	
Appendix B Questions and Open Issues	
Appendix C Differences from D9712048	
Appendix D Miscellaneous Comments/Requirements