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

From: Juergen Quittek <[email-masked]>
Date: Tue, 20 Aug 2013 01:09:39 -0700

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

---

From: Brad Schoening <[email-masked]>
Date: Tue, 20 Aug 2013 17:05:22 +0000

Juergen,

My experience has been that usually a meter was just a meter.  While many
devices such as PoE switches and PDUs can internally meter, we have to
recognize that there is a real use case for stand-alone metering.
Intelligent smart meters from vendors such as Shark, SATEC, and Crompton
are but a few examples of these widely used products   An ethernet switch
is a device who's primary purpose is networking, but may have metering
relationships.  But a smart meter is a device with the primary purpose of
metering.  

A common sense approach to classification should be more than adequate to
distinguish between products which consume energy to provide some
function, products that primarily produce energy, and products which are
designed for metering.  If we clarify that classification should involve
the primary purpose of a device it would this address this nit?

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.

Regards,

Brad

On 8/20/13 1:09 AM, "Juergen Quittek" <[email-masked]> wrote:

>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.
>
>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]
>https://www.ietf.org/mailman/listinfo/eman

---

From: "John Parello (jparello)" <[email-masked]>
Date: Tue, 20 Aug 2013 17:39:42 +0000

+1 on that Brad.

The category broadly classifies the device so a mgt system can determine if its behaving beyond its intent. For example power in the wrong direction from a producer (motor or or solar panel for example) that starts to consume.

So the category attribute answered the question "is a"

The power interface by their by their nature only measure power so it "is" not a meter but "can" measure. A meter can contain power interfaces.

So if you are looking for a capability  first I suggest not using the word "meter" to answer that question.  What you are looking for is "measure".  

A device is a "meter" and can "measure". An interface can "measure"  but "is not" a meter (a meter may contain multiple power interfaces). If you use the word "meter" there for capability then yes thats confusing but we are not doing that.

See inline

Jp

Sent from my iPad 
(expect ridiculous spelling mistakes) 

>> distributors at the same time.
[jp] for poe switch : is a "consumer", contains power interfaces that can "measure". A switch is certainly not a meter.  I proposed "distributor" as another category for pdu and/or a Poe switch. That may be clearer.

The model reads well to me with a clear distinction between category and capability to me. Don't see how that's broken unless you use meter as a capability which I agree is wrong but we don't do that.

>> available as 'metered'. It appears strange to classify the device as
[jp] you're confusing "is a" versus "can" and overloading meter in both those attributes. Meter is a classification not a capability. Measuring is the capability.

>> model circuit breaker capability (control) at power interfaces as well.
[jp] sounds like you want an additional field for capabilities. We had that in the model quite some time ago and from feedback deleted that from the Mib and framework. Are your proposing we revisit that issue and then add capability back? IMO and experience these capability type attributes need a registry and then get used rather loosely when implemented. So I think it much simpler to categorize devices and component broadly and then the capability is inferred from the presence of a measurement with caliber. Much simpler.

Jp

---

From: "John Parello (jparello)" <[email-masked]>
Date: Tue, 20 Aug 2013 17:51:45 +0000

<snip>

> smart meters, in particular sub-meters, are a key part of real time energy

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

---

From: Bruce Nordman <[email-masked]>
Date: Tue, 20 Aug 2013 11:44:20 -0700

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]> wrote:

> 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".
>

-- 
*Bruce Nordman*
Lawrence Berkeley National Laboratory
*nordman.lbl.gov*
[email-masked]
510-486-7089
m: 510-501-7943

---

From: "John Parello (jparello)" <[email-masked]>
Date: Tue, 20 Aug 2013 19:17:01 +0000

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

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>

Jp

> Regards,
>
> Brad
>
> On 8/20/13 1:09 AM, "Juergen Quittek" <[email-masked]<mailto:[email-masked]>> wrote:
>
>> Dear all,
>>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
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

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 27 Aug 2013 01:53:42 -0700

Hi Brad,

Thanks for your replies. I am still on vacation. That's why I did not answer immediately. Please see replies inline. 

> relationships.  But a smart meter is a device with the primary purpose of

I fully agree that there are devices that have energy metering as their primary purpose. Similarly, we have probe devices in the Internet with their that have traffic metering as their main purpose. But we in the Internet we still can live well without having a special MIB variable classifying a device as 'probe'. Why do we need this for energy management?
> 
> A common approach to classification should be more than adequate to

You say 'yes' for modeling the metering capability. But if you only indicate the capability for devices that have metering as their main funktion, then you rather mean 'no'. What you want is not anymore capability modeling but device categorization. 

Cheers,
    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 27 Aug 2013 02:06:10 -0700

Hi John,

I have the same answer to you as for Brad. What you want is categories for devices, not capability modeling. 

Then my question is: do we need this? We live well in the Internet without probes having a MIB object saying: "I am a probe".

Of course, a well designed network management system may classify devices and that is probably what EnergyWise does as well for meters, consumers, etc. The question is how much of the energy management system design needs to be pushed down to the devices?

If we think we need more for energy management than we have so far needed for managing traffic in the Internet, I would like to understand why. 

Thanks,
    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 27 Aug 2013 02:09:02 -0700

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]>:

> On Aug 20, 2013, at 11:44 AM, "Bruce Nordman" <[email-masked]> wrote:
> 
>> On Tue, Aug 20, 2013 at 10:51 AM, John Parello (jparello) <[email-masked]> wrote:
>>> 
>>> <snip>
>>> 
>>> >
>> nordman.lbl.gov

---

From: Brad Schoening <[email-masked]>
Date: Tue, 27 Aug 2013 14:23:36 +0000

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,

Thanks,
    Juergen

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

Jp

Sent from my iPad

--Bruce

<snip>

Jp

_______________________________________________ eman mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/eman

---

From: "John Parello (jparello)" <[email-masked]>
Date: Tue, 27 Aug 2013 15:08:19 +0000

Thanks Brad,

JQ to answer your two question I think Brad addressed the latter it but in simple language terms. A meter (n) is a device that measures (v) thus performs metering(g).

simple reference: http://en.wikipedia.org/wiki/Electricity_meter

Your second question and comment on category we seem to agree. The attribute  is category so yes I was modeling category not capability and labelled the attribute as such.

As to why we would need categorization you contended that we don't do that in internet modeling of devices today. We do. Each mib is a broad classification and I added category so as to simplify the need for sub-classes of both devices and components.  For non mib implementation this is simpler than subclassing both device and component.

As Brad references from 201p they have classes to distinguish these categories we can certainly do that if that's clearer but imo a category was simpler and would lead to fewer MIBs and keep it simple with device and component.

Jp

________________________________
From: Brad Schoening [[email-masked]]
Sent: Tuesday, August 27, 2013 7:23 AM
To: Juergen Quittek; John Parello (jparello)
Cc: eman mailing list
Subject: Re: [eman] eman framework issue: How to model a meter?

Juergen,

Regards,

Brad

Dear all,

Thanks,
    Juergen

Jp

Sent from my iPad

--Bruce

<snip>

Jp

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 30 Aug 2013 19:43:19 +0200

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]>:

> From: Juergen Quittek <[email-masked]>
> To: "John Parello (jparello)" <[email-masked]>
> Cc: eman mailing list <[email-masked]>
> _______________________________________________ eman mailing list [email-masked] https://www.ietf.org/mailman/listinfo/eman