Subject: Re: [eman] eman framework issue: How to model a meter?

From: Brad Schoening <[email-masked]>
Date: Thu, 5 Sep 2013 02:09:58 +0000

Juergen,

You're earlier question on this brought up a really important point.  We ought to be very clear between the definitions of metering and measuring.  Measurements are usually just instantaneous, for power or energy over a small time period.   Metering involves continuous measurement of voltage and current with a totalizing function over one or more time periods.

From: Juergen Quittek <[email-masked]<mailto:[email-masked]>>
Date: Fri, 30 Aug 2013 19:43:19 +0200
To: Brad Schoening <[email-masked]<mailto:[email-masked]>>
Cc: "John Parello (jparello)" <[email-masked]<mailto:[email-masked]>>, eman mailing list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [eman] eman framework issue: How to model a meter?

Hi Brad,

Thank you for the explanation. So, do I understand correctly that if you measure power you do not meteri, but if you measure energy you are?

Thanks,
    Juergen

Am 27.08.2013 um 16:23 schrieb Brad Schoening <[email-masked]<mailto:[email-masked]>>:

Juergen,

Metering is generally used when there is a continuos flow with the amount totalized.  Metering is usually facilitated by the presence of a physical meter which may have to meet regulatory requirements.  In the US, electric meters are divided into "Revenue Grade" and "Non-Revenue Grade" classes.

This is a noteworthy point, as an electrical device such as a PoE switch may be able to measure its instantaneous energy consumption, but typically doesn't have the ability to meter it and totalized it over time periods.

Regards,

Brad

From: Juergen Quittek <[email-masked]<mailto:[email-masked]>>
Date: Tue, 27 Aug 2013 02:09:02 -0700
To: "John Parello (jparello)" <[email-masked]<mailto:[email-masked]>>
Cc: eman mailing list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [eman] eman framework issue: How to model a meter?

Dear all,

Unfortunately, I am not a native speaker. Can someone explain to me the exact difference between 'metering' and 'measuring'?

Thanks,
    Juergen

Am 20.08.2013 um 12:17 schrieb "John Parello (jparello)" <[email-masked]<mailto:[email-masked]>>:

Good catch let's change "perform metering" to "perform measuring" then yes go with simple.

So broad categorization of the device/component and continue to leave complex capability modeling out.

Jp

Sent from my iPad
(expect ridiculous spelling mistakes)

On Aug 20, 2013, at 11:44 AM, "Bruce Nordman" <[email-masked]<mailto:[email-masked]>> wrote:

The current draft of the EMAN framework says:
  "A meter is a type Energy Object and any Energy Object can perform metering."

This seems to indicate that devices can meter, components can meter, and power
interfaces can meter.  On the other hand, Juergen notes that the meter classification
is not available to power interfaces.  This appears to be a contradiction.

It is possible to require declaring a "primary function" for a device, including whether it is a
device that can only perform metering, but that seems to be an unnecessary complication
and not derivative of any requirement.

Juergen's point is that metering (or measuring--I defer on that choice of wording) can be
simply and flexibly modeled as just a capability that any EO can have.  It is unnecessary
to make the Framework more complicated than that.  There are plenty of additional
complications that could be added that don't derive from any requirement.

--Bruce

On Tue, Aug 20, 2013 at 10:51 AM, John Parello (jparello) <[email-masked]<mailto:[email-masked]>> wrote:

<snip>

>
> You ask "Do we need to model metering capability at all"?  Yes, because
> smart meters, in particular sub-meters, are a key part of real time energy
> monitoring.
>

Just to be clear we used "meter" is a type of device (which acknowledges you other points, and if you want to model capability the value would be "measuring". So a "metering capability" doesn't make sense. It would be "measuring capability".

Again we removed the capabilities attribute.

After quite some years deploying these systems that distinction is second  nature for me but we should be precise.

Jp

> Regards,
>
> Brad
>
> On 8/20/13 1:09 AM, "Juergen Quittek" <[email-masked]<mailto:[email-masked]>> wrote:
>
>> Dear all,
>>
>> Here is another framework issue: How to model metering capabilities of
>> devices?
>>
>> Our framework draft (draft-ietf-eman-framework-08) models metering
>> capability by categorizing devices and components into either a producer,
>> a comsumer, a meter, or a distributor, see pseudocode on page 43.
>>
>> I think this approach is broken. It may be useful for modeling simple
>> scenarios, but it does not work as general model.
>>
>> There are two problems with this approach.
>>
>> 1. The either-or classification. A meter is typically not just a meter,
>> but as well a consumer that consumes energy when doing it's job. A PDU
>> that meters power at it's outlets is a meter and a distributor and a
>> consumer. The same holds for a PoE switch. These are not either meters or
>> consumers, they are meters and consumers and some of them are also
>> distributors at the same time.
>>
>> 2. The categorization as 'meter' is only available for devices and
>> components, not for power interfaces. But obviously a device with
>> metering capabilities meters at (some of) its interfaces. Take the PoE
>> switch that meters power at some or all of its PoE outlets. It would be
>> natural to label the power interfaces at which metering capabilities are
>> available as 'metered'. It appears strange to classify the device as
>> 'meter'.
>>
>> The basic question here is: Do we need to model metering capability at
>> all?  If yes, we should model it as an attribute, not as a category; and
>> we should model it as attribute of the power interfaces as well.
>>
>> BTW, if we model metering capability (monitoring), we should consequently
>> model circuit breaker capability (control) at power interfaces as well.
>>
>> Cheers,
>>  Juergen
>> _______________________________________________
>> eman mailing list
>> [email-masked]<mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/eman
>
> _______________________________________________
> eman mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/eman
_______________________________________________
eman mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eman

--
Bruce Nordman
Lawrence Berkeley National Laboratory
nordman.lbl.gov<http://nordman.lbl.gov>
[email-masked]<mailto:[email-masked]>
510-486-7089
m: 510-501-7943
_______________________________________________
eman mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eman
_______________________________________________ eman mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/eman