Re: Fwd: MC Form

CellNet supports this as well. Thank you.

Chris King


At 07:25 AM 12/17/98 -0500, Ken Prevatte wrote:
>
>I'd like to lend Schlumberger's support for Kathy's suggestion that meter
>manufacturer's be allowed to submit the MC form for approval by each UDC.
>This will indeed allow meter manufacturer's to be more pro active and
>therefore make life a bit easier for UDCs and ESPs.  New meter types aren't
>introduced to the market in great numbers, so this should not add any
>administrative burden.  In fact, this promises to streamline the process by
>eliminating possible confusion from having all the ESPs submit this
>information independent of the manufacturers.
>
>The clarifications Kathy asks for would be helpful as most of the data
>requested is programmable for solid-state metering products.
>
>Thanks,
>Ken Prevatte
>
>>Resent-From: admin@ora.ca.gov
>>Resent-Date: Wed, 16 Dec 1998 14:52:03 -0800
>>X-Lotus-FromDomain: ABB_USTRA@ABB_US01
>>From: kathy.smith@ustra.mail.abb.com
>>To: tariff@dradmin.cpuc.ca.gov, tariffweb@dradmin.cpuc.ca.gov
>>cc: pat.m.corrigan@ustra.mail.abb.com, ron.d.pate@ustra.mail.abb.com
>>Date: Wed, 16 Dec 1998 17:51:05 -0500
>>Subject: MC Form
>>Sender: tariff-request@smtp.ora.ca.gov
>>
>>A lot of effort has obviously been put into the Direct Access Metering
>>Handbook - it's a great accomplishment!  In reviewing  it, I noticed that
>>only an ESP can submit a Meter Characteristics (MC) form, and that an MC
>>form must be submitted for each meter type before it can be installed in a
>>given UDC's service territory.  The UDC has up to 30 days to process the
>>form.  It is not clear to me if this process changes if/when there is a
>>CPUC list of approved meter types - whether those meter types will
>>automatically be allowed by UDCs' systems, or an MC form will still have to
>>be submitted to each UDC.
>>
>>As a meter manufacturer, ABB would like to have the ability to submit an MC
>>form to a UDC for processing.  A manufacturer's competitive advantages
>>include being able to be pro-active and responsive to the marketplace, and
>>being able to meet customers' tight deadlines.  Not allowing manufacturers
>>to submit MC forms limits their ability to respond to customers, and
>>therefore limits their competitive edge.  Meter manufacturers do not
>>typically come out with lots of new meter styles in a given year, so I
>>don't believe there would be an excessive number of requests.
>>
>>I will be unable to attend the meetings in January, but request that this
>>be discussed at the OCC or Meter Specific meeting.  In my absence, Phaser
>>has agreed to "champion" the issue.  If there is a legitimate business
>>reason why a manufacturer should not be able to sumbit an MC, please let us
>>know.
>>
>>In light of the above request, I asked one of our meter engineers to review
>>the MC form to verify we could provide all the data.  We have the following
>>questions about some of the fields.  It may be helpful to clarify these
>>definitions whether manufacturers are allowed to submit the form or not -
>>if we have the questions, a new ESP or MSP may also have the same
>>questions.
>>
>>Thanks!
>>
>>List of Questions about MC Fields:
>>Register Type is defined as "The type of register designated by the
>>manufacturer that the meter uses to record and store energy usage".  Does
>>this mean solid state vs. electromechanical?  Or does it mean demand, TOU,
>>etc?
>>
>>Meter Kw is defined as "the watthour per pulse value programmed into a
>>solid state meter/recorder, with a formula of Ke = Pulse Constant / Billing
>>Constant x 1000."  Our Ke is the Kh divided by the P/R, which does provide
>>a watthour per pulse value as required.  We are not sure exactly what is
>>meant by  Pulse Constant and Billing Constant.
>>
>>Pulse Multiplier is defined as "the factor used on solid state meters to
>>convert pulses of energy to kilowatt usage per hour, also known as the
>>pulse constant."  The formula is provided as "Billing Constant x Ke / 1000
>>= Pulse Multiplier".  Again, what is the Billing Constant?
>>
>>Dial K (Register Constant) is defined as "the multiplier applied to the
>>register reading to obtain kilowatthours (does not include CT, PT ratios)."
>>We are familiar with a term Kr as register constant, but it typically does
>>include CT and PT ratios.   CT and PT ratios are not available until the
>>meter is actually installed, or you at least know where the meter will be
>>installed - they are not values that you can provide for a meter type.
>>Please confirm that the Dial K value is not expected to include CT and PT
>>ratios.
>>
>>Register Ratio, defined as "the number of revolutions of the gear meshing
>>with the worm or pinion on the rotating element for one revolution of the
>>first dial pointer", applies to electromechanical meters.   Please confirm
>>that this is not expected for solid state meters.
>>
>>Meter capability requires that you "show the number of dials (on mechanical
>>meter) / display segments (on solid state meter) and decimal....".  The
>>total number of display segments available on our solid state meter can be
>>provided, but the customer programs the actual number of segments to be
>>displayed.  The customer can also program the number of decimal places to
>>be displayed.  Please clarify what the expectations are here - just the
>>maximum possible values?  Actual values can vary with each meter
>>installation as they are programmable.
>>
>>TOU Capability requires that you "indicate whether or not there is TOU
>>display capability for the following time periods: On, Off, Mid,
>>Super-Off."  Please confirm that what is requested is an indication of
>>whether the meter has the ability to display TOU periods - again, whether
>>the meter actually displays them (or actually uses a TOU Schedule) is
>>programmable.  Also, the meter does not have specific time period
>>associations - I assume if a programmable meter has four TOU time periods
>>it would be considered to have On, Off, Mid, and Super-Off capabilities.
>>
>>IDR Capability requests that you indicate the demand interval, defined as
>>"the time increment, in minutes, used to record demand data; for example,
>>energy usage may be recorded every 5, 15, or 30 minutes."  Again, this is
>>programmable.  A given meter type is not limited to one demand interval.  A
>>list of all possible demand intervals for the meter type could be provided,
>>but the actual programmed value can change from installation to
>>installation.   Also, this is listed as "demand interval" but is under IDR
>>capability.  Please clarify what is required, and if this is really the
>>demand interval (such as used by a demand meter for peak demand, or a TOU
>>meter for TOU demand).
>>
>>IDR Capability also requests the # of Channels, defined as "the maximum
>>number of channels on the meter/recorder".  Please confirm that this is the
>>maximum number the meter type is capable of - again, the number of channels
>>actually used is programmable in the meter.
>>
>>IDR Capability also requests the Interval Length, defined as "the time
>>increment, in minutes, used to record interval data; for example, usage may
>>be recorded every 5, 15, or 30 minutes."  Again, the actual interval length
>>is programmable in the meter.  A list of all possible interval lengths
>>supported by the meter type could be provided, but the actual programmed
>>value can change from installation to installation.  Please clarify what is
>>required.
>> 
>
>


.
References: