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

Brad Schoening <brads@coraid.com> Tue, 20 August 2013 17:06 UTC

Return-Path: <brads@coraid.com>
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 E517D11E8273 for <eman@ietfa.amsl.com>; Tue, 20 Aug 2013 10:06:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 3bpczNAoDSf7 for <eman@ietfa.amsl.com>; Tue, 20 Aug 2013 10:06:10 -0700 (PDT)
Received: from server506.appriver.com (server506j.appriver.com [50.56.144.148]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3F011E8247 for <eman@ietf.org>; Tue, 20 Aug 2013 10:05:57 -0700 (PDT)
X-Note-AR-ScanTimeLocal: 8/20/2013 12:05:27 PM
X-Policy: GLOBAL - coraid.com
X-Policy: GLOBAL - coraid.com
X-Primary: brads@coraid.com
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-84/SG:2 8/20/2013 12:04:30 PM
X-GBUdb-Analysis: 0, 10.242.229.139, Ugly c=1 p=-0.944557 Source White
X-Signature-Violations: 0-0-0-7096-c
X-Note-419: 15.5998 ms. Fail:0 Chk:1343 of 1343 total
X-Note: SCH-CT/SI:0-1343/SG:1 8/20/2013 12:05:12 PM
X-Note: Spam Tests Failed:
X-Country-Path: UNKNOWN->PRIVATE->UNITED STATES
X-Note-Sending-IP: 10.242.229.139
X-Note-Reverse-DNS:
X-Note-Return-Path: brads@coraid.com
X-Note: User Rule Hits:
X-Note: Global Rule Hits: G340 G341 G342 G343 G347 G348 G455
X-Note: Encrypt Rule Hits:
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [10.242.229.139] (HELO smtp.exg6.exghost.com) by server506.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 11061270; Tue, 20 Aug 2013 12:05:27 -0500
Received: from DAGN05C-E6.exg6.exghost.com ([169.254.3.218]) by HT05-E6.exg6.exghost.com ([10.242.230.112]) with mapi id 14.03.0123.003; Tue, 20 Aug 2013 12:05:22 -0500
From: Brad Schoening <brads@coraid.com>
To: Juergen Quittek <ietf@quittek.at>, eman mailing list <eman@ietf.org>
Thread-Topic: [eman] eman framework issue: How to model a meter?
Thread-Index: AQHOnXyszg2BALUwJE2Ri+M1j328Q5meMmYA
Date: Tue, 20 Aug 2013 17:05:22 +0000
Message-ID: <CE38E868.CFE88%brads@coraid.com>
In-Reply-To: <F9AC12FC-49D5-4CD0-886C-6AE80C442F25@quittek.at>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.14.0.111121
x-originating-ip: [50.56.144.247]
x-rerouted-by-exchange:
Content-Type: text/plain; charset="us-ascii"
Content-ID: <53F136F82A051A42BD3D03C025858910@fwd6.exghost.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Tue, 20 Aug 2013 17:06:15 -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" <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