Subject: [eman] Requirements comments, part II

From: Bruce Nordman <[email-masked]>
Date: Fri, 8 Jul 2011 00:25:09 -0700

Part II:

 5. Required Information on Powered Entities

  It would be helpful to identify variables that are static vs. those that
are dynamic.

  There are some that are absolutely static, and others that just rarely
change.

5.1.1 Type of powered entity

  Add “according to some standard classification”.

5.2 Power State

  I disagree that a device should have multiple power state sets.  This puts
the

  burden of translating between sets on the device, when it is much better
put

  on the management system.  In an email from May 3, Juergen S noted:

    “Traditionally, it was always assumed that an SNMP management system

     can more easily adapt to devices than the other way round.”

  Also the first three sentences of paragraph four should be dropped.

5.2.1 Actual Power State

  There are transition states, when a device is in the process of moving

  from one long-term stable state to another.  I think this fact should be

  mentioned, though I don’t think we should attempt to model them.

  The expectation should be that these are mapped into the On state,

  since that will most closely resemble its power levels.

5.3 Power inlet and power outlet

  I am not fond of inlet and outlet but don’t have a better pair of terms to
suggest.

  Do we anticipate that these may be used for components of devices, or

  only for entire devices?

5.3.4 Availability of power

  In most cases I agree that this is just On or Off.  However, PoE and USB

  (and emerging standards such as UPAMD) have a mode in which only

  a minimal amount of power is provided, to enable a device to request

  more.  So, I propose that a “Minimum” (or similar term) be added as

  a possible third state for this.  This could also apply to control
requirements.

5.4.2 Confidence in power values

  This sounds “mechanism” or “method” rather than “confidence”.

  Also, I would combine this with the following accuracy requirement,

  since estimation could vary dramatically in accuracy depending on

  the product.  Or, drop this requirement entirely and stick only to

  accuracy.

5.4.8 Power supply impedance

  I am not an engineer, but is this needed?  I ask since I don’t remember

  ever seeing it used in my energy efficiency research.  Other metrics such

  as power factor are often raised.

5.4.9 Time series of power values

  The second half of this implies that time series functionality can be

  accomplished by means other than EMAN itself.  I heartily agree.

  This same issue arises in 5.5 and 5.5.2 – I think should be outside of
EMAN.

5.5. Energy

  I think the time component of accumulated energy values should be

  relative to the first time the entity is used – that is, never reset, so

  not on “restart”.  A monitoring system can do any intervaling it wants

  to – there is no reason to burden or complicate the device, and we don’t

  want to reset the meter else risk great potential confusion.

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

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 11 Jul 2011 13:48:51 +0000

Hi Bruce,

Am 08.07.11 09:25 schrieb "Bruce Nordman" unter <[email-masked]>:

>   It would be helpful to identify variables that are static vs. those that are
> dynamic.

Right. But I think this can be done in the framework or the MIB module.
The Battery MIB clearly separates static from dynamic values.

>   Add ³according to some standard classification².

OK.

I another discussion we were arguing about removing or not removing section
5.1.1 on entity types. I had it deteled but now put it back and added a new
open issue.

>   burden of translating between sets on the device, when it is much better put
>    ³Traditionally, it was always assumed that an SNMP management system
>     can more easily adapt to devices than the other way round.²

I think we had consensus on multiple states in the WG.
Let's discuss this separately.

>   Also the first three sentences of paragraph four should be dropped.

Done.

>   mentioned, though I don¹t think we should attempt to model them.

What would need to be added? just a note?

>   I am not fond of inlet and outlet but don¹t have a better pair of terms to
> suggest.

I see them particularly for entire devices.
I would appreciate good proposals for better terms.
 
>   more.  So, I propose that a ³Minimum² (or similar term) be added as

agreed. However, I would like to read 803.at again before fixing the term.
Added to open issues.

>   This sounds ³mechanism² or ³method² rather than ³confidence².

Added to open issues.

>   I am not an engineer, but is this needed?  I ask since I don¹t remember

added to open issues.

>   This same issue arises in 5.5 and 5.5.2  I think should be outside of EMAN.

What do you mean with 'means other than EMAN?

>   relative to the first time the entity is used  that is, never reset, so
>   not on ³restart².  A monitoring system can do any intervaling it wants
>   to  there is no reason to burden or complicate the device, and we don¹t

that would be a tough requirement for devices without persistent
(non-volatile) storage. Wouldn't this bee too strong for a requirement?

    Juergen

---

From: Benoit Claise <[email-masked]>
Date: Mon, 25 Jul 2011 23:36:59 -0400

Hi Juergen, Bruce,
> Hi Bruce,
>
> Am 08.07.11 09:25 schrieb "Bruce Nordman" unter<[email-masked]>:
>
>> Part II:
>>
>>
Agreed.

Regards, Benoit (as a contributor)