Return-Path: X-Original-To: eman@ietfa.amsl.com Delivered-To: eman@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E72B11E8111 for ; Fri, 30 Aug 2013 10:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.853 X-Spam-Level: X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FRYV9puO1Qc for ; Fri, 30 Aug 2013 10:43:31 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 059DE21F9EB8 for ; Fri, 30 Aug 2013 10:43:31 -0700 (PDT) Received: from [10.42.187.143] (tmo-097-25.customers.d1-online.com [80.187.97.25]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0LqacI-1VtSNE0CQM-00eIR3; Fri, 30 Aug 2013 19:43:25 +0200 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-CAEC3AD5-9B81-4E3D-9690-194863951C6F Content-Transfer-Encoding: 7bit Message-Id: <22513F63-D109-413B-8AD8-F22C90626F47@quittek.at> X-Mailer: iPhone Mail (10B329) From: Juergen Quittek Date: Fri, 30 Aug 2013 19:43:19 +0200 To: Brad Schoening X-Provags-ID: V02:K0:S4O1WnNngox6fL+KKKg3p5eWHm5BdYMvNFX532S4M3a LO88l4W/g3aGwln2lL15OdvUQtjMcPEZIJYL+g9ciVZRCffZZl 4uoetKhlpMH2MkxSQxDvgg6Qo8NWk+6lZUHFVa0afa+brI/cmt k7T2fVEmYVsZHigfKWUf5X+Cr7gWrWiYkI7dUW99lUYP9ezIL3 /qslpByBcEu67vKSBB+FeK93JYvaMRqMcl+S74X2oH9CGDdyyq NDrU1zupHf8eJ08SrKB/baVb5E+bCvkiFLJsTO26oFtiRDN1Gb ELb53EyO6Fgvlopcl9FwgEKKD7th2IMBpV14GBmbtn7q1Os3ZY mhU0ABF1Cjn+xK9F6q1g26IBAJzyXYMPwMZXNdfdb Cc: eman mailing list Subject: Re: [eman] eman framework issue: How to model a meter? X-BeenThere: eman@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussions about the Energy Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 17:43:42 -0000 --Apple-Mail-CAEC3AD5-9B81-4E3D-9690-194863951C6F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Brad, Thank you for the explanation. So, do I understand correctly that if you mea= sure power you do not meteri, but if you measure energy you are? Thanks, Juergen=20 Am 27.08.2013 um 16:23 schrieb Brad Schoening : > Juergen, >=20 > Metering is generally used when there is a continuos flow with the amount t= otalized. Metering is usually facilitated by the presence of a physical met= er which may have to meet regulatory requirements. In the US, electric mete= rs are divided into "Revenue Grade" and "Non-Revenue Grade" classes. >=20 > This is a noteworthy point, as an electrical device such as a PoE switch m= ay be able to measure its instantaneous energy consumption, but typically do= esn't have the ability to meter it and totalized it over time periods. >=20 > Regards, >=20 > Brad >=20 > From: Juergen Quittek > Date: Tue, 27 Aug 2013 02:09:02 -0700 > To: "John Parello (jparello)" > Cc: eman mailing list > Subject: Re: [eman] eman framework issue: How to model a meter? >=20 > Dear all, >=20 > Unfortunately, I am not a native speaker. Can someone explain to me the ex= act difference between 'metering' and 'measuring'? >=20 > Thanks, > Juergen >=20 > Am 20.08.2013 um 12:17 schrieb "John Parello (jparello)" : >=20 >> Good catch let's change "perform metering" to "perform measuring" then ye= s go with simple. >>=20 >> So broad categorization of the device/component and continue to leave com= plex capability modeling out. >>=20 >> Jp >>=20 >> Sent from my iPad=20 >> (expect ridiculous spelling mistakes)=20 >>=20 >> On Aug 20, 2013, at 11:44 AM, "Bruce Nordman" wrote: >>=20 >>> The current draft of the EMAN framework says: >>> "A meter is a type Energy Object and any Energy Object can perform met= ering." >>>=20 >>> 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 c= lassification >>> is not available to power interfaces. This appears to be a contradictio= n. >>>=20 >>> It is possible to require declaring a "primary function" for a device, i= ncluding whether it is a >>> device that can only perform metering, but that seems to be an unnecessa= ry complication >>> and not derivative of any requirement. >>>=20 >>> Juergen's point is that metering (or measuring--I defer on that choice o= f wording) can be >>> simply and flexibly modeled as just a capability that any EO can have. I= t is unnecessary >>> to make the Framework more complicated than that. There are plenty of a= dditional >>> complications that could be added that don't derive from any requirement= . >>>=20 >>> --Bruce >>>=20 >>>=20 >>>=20 >>> On Tue, Aug 20, 2013 at 10:51 AM, John Parello (jparello) wrote: >>>>=20 >>>> >>>>=20 >>>> > >>>> > You ask "Do we need to model metering capability at all"? Yes, becau= se >>>> > smart meters, in particular sub-meters, are a key part of real time e= nergy >>>> > monitoring. >>>> > >>>>=20 >>>> Just to be clear we used "meter" is a type of device (which acknowledge= s 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 "meas= uring capability". >>>>=20 >>>> Again we removed the capabilities attribute. >>>>=20 >>>> After quite some years deploying these systems that distinction is seco= nd nature for me but we should be precise. >>>>=20 >>>> Jp >>>>=20 >>>>=20 >>>>=20 >>>> > Regards, >>>> > >>>> > Brad >>>> > >>>> > On 8/20/13 1:09 AM, "Juergen Quittek" wrote: >>>> > >>>> >> Dear all, >>>> >> >>>> >> Here is another framework issue: How to model metering capabilities o= f >>>> >> devices? >>>> >> >>>> >> Our framework draft (draft-ietf-eman-framework-08) models metering >>>> >> capability by categorizing devices and components into either a prod= ucer, >>>> >> a comsumer, a meter, or a distributor, see pseudocode on page 43. >>>> >> >>>> >> I think this approach is broken. It may be useful for modeling simpl= e >>>> >> 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 met= er, >>>> >> but as well a consumer that consumes energy when doing it's job. A P= DU >>>> >> 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 mete= rs 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 P= oE >>>> >> 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 a= t >>>> >> 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 consequ= ently >>>> >> model circuit breaker capability (control) at power interfaces as we= ll. >>>> >> >>>> >> Cheers, >>>> >> Juergen >>>> >> _______________________________________________ >>>> >> eman mailing list >>>> >> eman@ietf.org >>>> >> https://www.ietf.org/mailman/listinfo/eman >>>> > >>>> > _______________________________________________ >>>> > eman mailing list >>>> > eman@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/eman >>>> _______________________________________________ >>>> eman mailing list >>>> eman@ietf.org >>>> https://www.ietf.org/mailman/listinfo/eman >>>=20 >>>=20 >>>=20 >>> --=20 >>> Bruce Nordman >>> Lawrence Berkeley National Laboratory >>> nordman.lbl.gov >>> BNordman@LBL.gov >>> 510-486-7089 >>> m: 510-501-7943 >> _______________________________________________ >> eman mailing list >> eman@ietf.org >> https://www.ietf.org/mailman/listinfo/eman > _______________________________________________ eman mailing list eman@iet= f.org https://www.ietf.org/mailman/listinfo/eman --Apple-Mail-CAEC3AD5-9B81-4E3D-9690-194863951C6F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
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 <brads@coraid.com>:

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 <ietf@quittek.at>
Date: Tue, 27 Aug 2013 02:09:02 -0700
To: "John Parello (jparello)" <jparello@cisco.com>
Cc: eman mailing list <eman@ietf.org>
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)" <jparello@cisco.com>:

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" <bnordman@lbl.gov> 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) <jparello@cisco.com> 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" <ietf@quittek.at> 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
>> eman@ietf.org
>> https://www.ietf.org/mailman/listinfo/eman
>
> _______________________________________________
> eman mailing list
> eman@ietf.org
> https://www.ietf.org/mailman/listinfo/eman
_______________________________________________
eman mailing list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman



--
Bruce Nordman
Lawrence Berkeley National Laboratory
nordman.lbl.gov
BNordman@LBL.gov
510-486-7089
m: 510-501-7943
_______________________________________________
eman mailing list
eman@ietf.org
https://www.ietf.org/mailman/listinfo/eman
_______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman
--Apple-Mail-CAEC3AD5-9B81-4E3D-9690-194863951C6F--