Subject: [eman] Feedback on Framework Draft

From: David Prantl <[email-masked]>
Date: Fri, 22 Jul 2011 22:54:27 +0200

Hello All,

my name is David Prantl, working for JouleX as a Solution Architect. I am summarizing
comments from myself and my colleagues Martin Paatz and Rene Seeber. We have an
Enterprise Energy Management Product and would like to comment on the latest
draft of the Energy Management Framework Draft - which we think is a great foundation
for a standardized approach to Energy Management.
Comments as bullet points below:

Energy Monitoring

*         We are Glad that Energy Quality and Demand are available as optional Values as this permits
us - if available from Energy Managed Objects - to deliver high accuracy Readings (based on
demand/total Energy delivered and not point measurements)

*         The Integration of Battery Information is crucial for shaving off energy during peak demand periods-
it is good to know this is already integrated, peak-demand handling is crucial in e.g. Japan.

Energy Managed Object Identification and Context
Today there are specifications for role/keyword/importance/category

*         The Keyword Concept for Grouping is extremely useful and has been integrated into our
Software for arbitrary Objects.

*         The Context Role (5.2.5) must specify more examples or rules on how the roles-tring should be populated,

e.g. contain standard definitions, otherwise they are only one more keyword.

However, we appreciate this additional Information field, and would in fact encourage more of these - but
with clearly defined recommendations in regards to content, see below.

*         There should be additional identification fields for at least vendor and product, e.g.
Cisco, WS-C2960G-48TC-L or Lenovo, W500
Otherwise there is no way to uniquely identify Energy Managed Objects (in respect to what kind of device
is behind it) - this becomes important when additional Information must be retrieved or presented.
E.g. when an outside mgmt-station maps Manufacturer Power States based on pre-known states for a
certain device-type

Energy Managed Object Relationships

*         energy topology information - the draft supports the concept of parent<->child mappings, but does not allow
for more complex energy topologies,

e.g. 2 circuits <-> 4 outlets <-> 4 Power Supplies <->
blade-chassis(info about chassis-draw, ps-draw)<->8 blades(info about blade/cpu-draw)
It is also not possible to "populate" the domain with information about these mappings, e.g. I cannot tell

the domain that server1 is powered by pdu1, plugA and pud2, plugB.

Energy Control

*         non-discrete power-states are not supported -> Section 5.5. specifies the possibility of mapping
"Manufacturer" Power States to the 12 Eman Power states, where there can be more than 12 Manufacturer
Power States. However, in the context of power-capping of Servers we have a "non-discrete" floating cap corresponding
to the Manufacturer Power State.
The Problem is that different Servers will have completely different ranges of supported cap-values, e.g. Server 1 has a dynamic range of 300-500Watt, Server2 has a range of 70-270Watts. Now let's assume Powerstate 9=400 Watts for Server1, but would be 170Watts for Server2. Which would mean I have to specify a Mapping for each Server-Model.
It would be far more practical if it would be possible to supply a key-value-pair with a certain power-state in Case the
State needs context such as a power-cap, I would then specify a state of e.g. 7 and supply the desired Cap in the kvp-field.

General Stuff.

*         (Page 6) 3. Terminology
Energy Management System is introduced as EnMS later EMS is used (e.g. Page 7).

*         Generally
parent child relationship can lead to a delayed measurement, especially with multiple generations
e.g.  1. child measures every 5 minutes -> parent every 4 minutes, this will lead to different offsets in the readings

Best Regards,
David

JouleX
David Prantl
Solution Architect
(M) +49 172 5835887
www.jouleX.net<http://www.joulex.net/>

ENTERPRISE GREEN IT

Follow us:
Twitter @JouleXnet<http://twitter.com/joulexnet>
JouleX on Facebook<http://www.facebook.com/home.php?#%21/pages/JouleX/103797146330542?ref=ts>
LinkedIn Profile<http://www.linkedin.com/companies/947868>

---

From: "John Parello (jparello)" <[email-masked]>
Date: Wed, 27 Jul 2011 11:41:06 -0700

HI David,

Thanks glad we have things in the draft that are useful. Hopefully we
can figure out how to meet you other needs.

Please see inline... 

From: David Prantl [mailto:[email-masked]] 
Sent: Friday, July 22, 2011 1:54 PM
To: [email-masked]
Subject: Feedback on Framework Draft

Hello All,

my name is David Prantl, working for JouleX as a Solution Architect. I
am summarizing

comments from myself and my colleagues Martin Paatz and Rene Seeber. We
have an

Enterprise Energy Management Product and would like to comment on the
latest

draft of the Energy Management Framework Draft - which we think is a
great foundation

Energy Monitoring

*         We are Glad that Energy Quality and Demand are available as
optional Values as this permits
us - if available from Energy Managed Objects - to deliver high accuracy
Readings (based on 
demand/total Energy delivered and not point measurements)

*         The Integration of Battery Information is crucial for shaving
off energy during peak demand periods-
it is good to know this is already integrated, peak-demand handling is
crucial in e.g. Japan.

[jp] thanks!

*         The Keyword Concept for Grouping is extremely useful and has
been integrated into our 
Software for arbitrary Objects.

*         The Context Role (5.2.5) must specify more examples or rules
on how the roles-tring should be populated,

e.g. contain standard definitions, otherwise they are only one more
keyword.

However, we appreciate this additional Information field, and would in
fact encourage more of these - but
with clearly defined recommendations in regards to content, see below.

[jp] Thanks we'll add guidance in the framework

*         There should be additional identification fields for at least
vendor and product, e.g. 
Cisco, WS-C2960G-48TC-L or Lenovo, W500
Otherwise there is no way to uniquely identify Energy Managed Objects
(in respect to what kind of device
is behind it) - this becomes important when additional Information must
be retrieved or presented.
E.g. when an outside mgmt-station maps Manufacturer Power States based
on pre-known states for a 
certain device-type

[jp] There's a discussion in the requirements for this. I proposed some
vendor,type,species information. What would work for you?

*         energy topology information - the draft supports the concept
of parent<->child mappings, but does not allow
for more complex energy topologies, 

e.g. 2 circuits <-> 4 outlets <-> 4 Power Supplies <-> 
blade-chassis(info about chassis-draw, ps-draw)<->8 blades(info about
blade/cpu-draw)
It is also not possible to "populate" the domain with information about
these mappings, e.g. I cannot tell

[jp] We added the notion of relationships between devices. We have
metered, powered,proxy,aggregation. For population we'll have to call
that our but the intent was to make the uuid's the link. We have to
settle on the use of a universal identifier first or what you want may
not be convenient or possible. I'll present a topology and let's see of
that suffices for you modeling purposes.

Energy Control

*         non-discrete power-states are not supported -> Section 5.5.
specifies the possibility of mapping 
"Manufacturer" Power States to the 12 Eman Power states, where there can
be more than 12 Manufacturer
Power States. However, in the context of power-capping of Servers we
have a "non-discrete" floating cap corresponding
to the Manufacturer Power State.
The Problem is that different Servers will have completely different
ranges of supported cap-values, e.g. Server 1 has a dynamic range of
300-500Watt, Server2 has a range of 70-270Watts. Now let's assume
Powerstate 9=400 Watts for Server1, but would be 170Watts for Server2.
Which would mean I have to specify a Mapping for each Server-Model.
It would be far more practical if it would be possible to supply a
key-value-pair with a certain power-state in Case the 
State needs context such as a power-cap, I would then specify a state of
e.g. 7 and supply the desired Cap in the kvp-field.

[jp] This one is interesting. We don't have a model for this so perhaps
some help on proposing one 

General Stuff.

Energy Management System is introduced as EnMS later EMS is used (e.g.
Page 7).

[jp] Thanks I'll try and clear that up. EnMS is a term from ISO500001
and EMS is an overloaded term meaning a computerized energy management
system and/or element management system.

*         Generally

parent child relationship can lead to a delayed measurement, especially
with multiple generations

e.g.  1. child measures every 5 minutes -> parent every 4 minutes, this
will lead to different offsets in the readings

[jp] Very true.  Would timestamps help here or is this something
inherent in the problem.

Thanks again!

Jp