Fwd: MC Form
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.
>
.
Follow-Ups: