Re: [eman] eman framework issue: How to model a meter?
Juergen Quittek <ietf@quittek.at> Fri, 30 August 2013 17:43 UTC
Return-Path: <ietf@quittek.at>
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 <eman@ietfa.amsl.com>; 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 <eman@ietfa.amsl.com>; 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 <eman@ietf.org>; 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: <CE422A2F.D57B1%brads@coraid.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <CE422A2F.D57B1%brads@coraid.com>
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 <ietf@quittek.at>
Date: Fri, 30 Aug 2013 19:43:19 +0200
To: Brad Schoening <brads@coraid.com>
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 <eman@ietf.org>
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 <eman.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eman>, <mailto:eman-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/eman>
List-Post: <mailto:eman@ietf.org>
List-Help: <mailto:eman-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eman>, <mailto:eman-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Aug 2013 17:43:42 -0000
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
- [eman] eman framework issue: How to model a meter? Juergen Quittek
- Re: [eman] eman framework issue: How to model a m… Brad Schoening
- Re: [eman] eman framework issue: How to model a m… John Parello (jparello)
- Re: [eman] eman framework issue: How to model a m… John Parello (jparello)
- Re: [eman] eman framework issue: How to model a m… Bruce Nordman
- Re: [eman] eman framework issue: How to model a m… John Parello (jparello)
- Re: [eman] eman framework issue: How to model a m… Juergen Quittek
- Re: [eman] eman framework issue: How to model a m… Juergen Quittek
- Re: [eman] eman framework issue: How to model a m… Juergen Quittek
- Re: [eman] eman framework issue: How to model a m… Brad Schoening
- Re: [eman] eman framework issue: How to model a m… John Parello (jparello)
- Re: [eman] eman framework issue: How to model a m… Juergen Quittek
- Re: [eman] eman framework issue: How to model a m… Brad Schoening