Subject: Re: [eman] Comments on eman requirements

From: Brad Schoening <[email-masked]>
Date: Mon, 5 Sep 2011 16:04:42 +0000

Hi Michael,

IEC 61000-4-30 appears to be a standard for benchmark measurement methods and testing.  It does not seem to include a data model for reporting and management over protocols such as IP or SNMP.  

Thanks,

Brad

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Suchoff
Sent: Wednesday, July 13, 2011 11:39 AM
To: Juergen Quittek; Mouli Chandramouli (moulchan)
Cc: eman mailing list
Subject: Re: [eman] Comments on eman requirements

A root cause for confusion may be WG's selection of IEC 61850 as power
quality standard.  61850 is used by power stations and utilities for
medium and high voltage systems - this is not appropriate for low
voltage AC systems where this group's work will be used.

A better choice would be IEC 61000-4-30 "Testing and Measuring
Techniques - Power Quality Measurement Methods".  An examination of
power quality meters will show this is the standard to which they are
designed.

-----Original Message-----
From: Juergen Quittek [mailto:[email-masked]] 
Sent: Wednesday, July 13, 2011 8:59 AM
To: Mouli Chandramouli (moulchan)
Cc: Michael Suchoff; eman mailing list
Subject: Re: [eman] Comments on eman requirements

Hi Mouli,

Let's come back to this after we have agreed on a definition for power.
Meanwhile I will look up how IEEE and IEC define "instantaneous power",
particularly in case of AC.

Thanks,

    Juergen

Am 13.07.2011 um 12:09 schrieb Mouli Chandramouli (moulchan):

> Hi Juergen,
> 
> I think there is some confusion on measurement - what is meant by
> instantaneous power measurement. 
> 
> For the sake of clarity, let us assume there is an external meter,
which
> measures the power of the electrical device at a given time instant
and
> it is possible to read the meter reading. The reported value is the
> power consumed by the device at that time - 100 watts...
> 
> I do not think the intent is to measure Alternating Current at the
> granularity of 50 or 60 sinusoidal cycles per second. Not sure if
there
> are even devices to measure current at that level. 
> 
> So, the meter does the averaging internally and reports the power
> consumed at a given time. From a energy monitoring or planning
> perspective, that would seem to be adequate. 
> 
> Any thoughts. 
> 
> Thanks
> Mouli
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Juergen Quittek
> Sent: Friday, July 08, 2011 2:17 PM
> To: Michael Suchoff
> Cc: eman mailing list
> Subject: Re: [eman] Comments on eman requirements
> 
> Dear Michael,
> 
> You are absolutely right. 
> And I wrote the same story already in an earlier message:
> 
> For AC power measurement there is always a reporting interval.
> 
> Thanks,
> 
>    Juergen
> 
> Am 07.07.2011 um 17:14 schrieb Michael Suchoff:
> 
>> AC power is not reported as an instantaneous value but as an average
-
> the minimum averaging time being 1/2 AC cycle.
>> 
>> A plot of the instantaneous AC power is a sinusoidal waveform at 2X
> the AC power frequency.  For example, assume V = 100V RMS, I = 1A RMS,
> F=60Hz with power factor 1.0.  The power waveform would be a 120Hz
> sinusoidal with amplitude 200 and average value 100.  The average
value
> is the active (real) power.
>> 
>> The power waveform can be explained mathematically using the product
> to sum formula we learned in high school trigonometry class....
>> 
>> Sin(a) * sin(b) = .5 * (cos(a-b) - cos(a+b)
>> 
>> "a" and "b" are frequency (phase term not shown for simplicity) which
> are identical.  Cos(a-b) = 0 which is the real component of power and
> whose average value is shown on a watt meter.  Cos(a+b) is the 2X
> frequency component whose average value is 0.
>> 
>> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of JinHyeock Choi
>> Sent: Wednesday, July 06, 2011 11:09 PM
>> To: Juergen Quittek
>> Cc: eman mailing list
>> Subject: Re: [eman] Comments on eman requirements
>> 
>> Dear Juergen
>> 
>> thanks for kind and thoughtful reply.
>> 
>>>> 1. Clarification of 'Power' and 'Energy'
>>>> 
>>>> Energy management concerns both 'power' and 'energy' and
>>>> now the term 'energy consmption' is used for both,
>>>> and sometimes brings forth confusion.
>>>> 
>>>> Maybe we can make it more clear
>>>> by attaching the unit to be measured (either watt or watthour).
>>>> For example such as
>>>> "amount of consumed energy measured by joule or watthour."
>>> 
>>> I see your point. The alternative would be adding a clarification to
>>> the terminology section. What about appending
>>> 
>>>  However, in this document the term "consumed energy" always refers
>>>  to an energy quantity and not to a power quantity.
>>> 
>>> to section 2.1 Energy?
>> 
>> fine with me.
>> 
>> Sometimes people have trouble distinguishng 'power' and 'energy'
>> at least that's the case for me.
>> (it has been a long while since I pored over Physics textbook.)
>> 
>> Though 'power' and 'energy' have different meanings
>> clearly defined in Physics,
>> their everyday usage can be intermingling
>> such as 'power efficiency' and 'energy efficiency'
>> 
>>>> 2. Power/ Energy and Time
>>>> Both power and energy are time dependent parameter.
>>>> 
>>>> When reporting 'power' or 'energy' value,
>>>> i) a specific moment or ii) a time interval
>>>> with which the measurement is made also should be provided.
>>> 
>>> Yes, that's a good point. I think for energy measurements this is
> covered
>>> by requirement 5.5.2.  Time intervals, but for power monitoring this
> is missing.
>>> 
>>> What about adding the following requirement?
>>> 5.4.2.  Power measurement interval
>>> 
>>>  The energy management standard must provide means for reporting the
>>>  corresponding time interval for which a power value is reported.  A
>>>  time interval can be very short for reporting approximations of
>>>  instantaneous power or rather long for reporting demand values.
>> 
>> In principle,
>> power itself is an instantateous value
>> and measured at a moment (not over interval).
>> 
>> So how about rephrasing
>> 
>>   The energy management standard must provide means for reporting the
>>   corresponding time or time interval for which a power value is
> reported.
>>   The power value can be measured at the corresponding time or
> averaged
>>   over the corresponding time interval.
>> 
>>>> 3. Power state and Energy consumption
>>>> 
>>>>> 5.5.3. Energy per power state
>>>>> 
>>>>> The energy management standard must provide means for reporting
the
>>>>> consumed energy individually for each power state.
>>>> 
>>>> Energy consumption depends on
>>>> not only 'power state' but also 'traffic load'.
>>>> 
>>>> To make sense out of the monitored 'power' or 'energy' value,
>>>> energy management system should also take into consideration
>>>> corresponding  'traffic rate (measured by bps)' or 'accumulated
>>>> traffic (measured by bits)'.
>>>> 
>>>> Otherwise it can't determine
>>>> whether high power consumption is from low energy efficiency
>>>> or high data traffic.
>>> 
>>> What would be the requirement?
>> 
>> How about
>> 
>>   The energy management standard must provide means for reporting the
>>   consumed energy individually for each power state,
>>   with which enegy management system can derive an average expected
>>   energy consumption for each power state.
>> 
>> to clarify the reason behind per-power state reporting
>>> A comment on the issue:
>>> Proportionality between traffic and energy is a tricky thing.
>>> I read reports on measurements at low-end routers that show
>>> decreasing energy consumption with increasing traffic.
>> 
>> Interesting.
>> Power consumption remaining the same irrespective of traffic load
>> is not unusual but power consumption inversely proportional
>> to traffic load is a novelty.
>> Can you give me a pointer?
>> 
>>>> 4. Power profile of powered entity
>>>> 
>>>> For the above purpose, it would be of help
>>>> for energy management system to be aware of
>>>> the energy efficiency of each powered device (or entity),
>>>> i.e. how much energy (joule) each device consumes per bit.
>>>> 
>>>> Ideally energy efficiency would be provided as
>>>> a power profile (or power model), a function
>>>> which maps served traffic (bits or bps) into consumed energy
(joule/
> watt).
>>>> 
>>>> I recommend
>>>> energy efficiency or power profile
>>>> to be included to the required information in Sec 5.
>>> 
>>> This would be a requirement for switches, routers, etc. only.
>>> For PCs, displays, light bulbs, it would not be applicable.
>> 
>> I see.
>> 
>>> Would it not be sufficient to just report the power and have the
> joule/bit
>>> be computed by a management system that reads the interface MIB
> modules
>>> if available?
>> 
>> ok.
>> 
>> For energy management,
>> power profile would be needed
>> but maybe better be acquired indirectly
>> via a kind of resolution scheme.
>> 
>>>>> 4.2. Identifying components of powered devices
>>>>> 
>>>>> The energy management standard must provide means for identifying
> not
>>>>> just entire devices as powered entities, but also individual
>>>>> components of powered devices.
>>>> 
>>>> Shall we also identify (or represent) the (subordinate)
relationship
>>>> between powered device and its individual components?
>>> 
>>> There are already standards for this available.
>>> Shall we still make a requirement out of it in order to clarify that
> this is
>>> needed for energy management as well?
>> 
>> Such representatin of subordinate relationship would be useful
>> but I'm not sure about making it a requirement.
>> If WG doesn't have a strong opinion about it,
>> let's leave it as it is. :-)
>> 
>>>>> 5.2.6. Maximum and average power per power state
>>>>> 
>>>>> The energy management standard must provide means for retrieving
> the
>>>>> maximum power and the average power as a typically static property
>>>>> for each supported power state.
>>>> 
>>>> Average power in which sense?
>>>> Just a arithmetic mean value between maximum and minimum power?
>>> 
>>> I was thinking about the average expected energy consumption in a
> particular power state.
>>> I admit that this may be difficult to predict.
>> 
>> yes,
>> even at the same power state,
>> enrgy consumption can vary substantially depending on traffic load.
>> 
>>> But before asking an entity to switch to another
>>> power state it would make sense to have information about the
chances
> of saving power
>>> and for avoiding to bring the device into a state that even consumes
> more power.
>> 
>> agree.
>> 
>>>>> 5.4. Power
>>>>> 
>>>>> For some network management tasks, it is required to obtain time
>>>>> series of power values (or energy consumption values).
>>>> 
>>>> I assume energy consumption value measured by watt.
>>>> Am I right?
>>> 
>>> No here it is either or: power or energy time series. But I see this
> is confusing.
>>> What about removing "(or energy consumption values)"?
>> 
>> ok. thanks for clarificaiton.
>> 
>>>>> 5.5. Energy
>>>>> 
>>>>> In order to monitor energy consumption in different power states,
> it
>>>>> is useful if entities record their energy consumption per power
> state
>>>>> and report these quantities.
>>>> 
>>>> Energy consumption varies according to power state and traffic
load.
>>>> How do you take 'traffic load' into consideration?
>>> 
>>> We do not have any generic term for load. If you can provide one,
> please send it.
>> 
>> 'bps' or '(accumulated) bit' would do for network equipments
>> such as router or switich.
>> 
>> However, for more generic work load,
>> I don't have a good idea.
>> 
>>>> Energy would be measured over time interval.
>>>> 
>>>> Would time series of energy values be measured
>>>> over the sequence of time intervals in 5.5.2?
>>> 
>>> Yes. There are different ways to do so.
>>> 
>>> A time series can contain values that give the total energy since
the
> last re-start
>>> up to an indicated measurement time. Alternatively, you can have
time
> series of energy
>>> consumption for consecutive time intervals, one value each. Or you
> can have this for
>>> overlapping time intervals. 5.5.2 shows all of them.
>> 
>> ok.
>> 
>> Please allow me to split hairs
>> cocnerning the terms 'series' and 'sequence'
>> which are currently both used in in 5.5.2 and 5.5.4.
>> 
>> Precisely speaking, in mathematics,
>> 'series' is the sum of the terms of 'sequence',
>> so in our context, 'sequence' is better.
>> 
>> Bets regards
>> 
>> JinHyeock
>> _______________________________________________
>> eman mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/eman
> 
> _______________________________________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eman

_______________________________________________
eman mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/eman

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Tue, 6 Sep 2011 05:39:00 -0500

Hi Michael,

Expanding on Brad's point - IEC 61000-4-30, it seems the standard is
focused on defining an standardized approach for instrumentation of
measuring devices and devices complying to this standard  - " This
standard ensures that different PQ instruments use the same definitions,
and measurement techniques, for various power quality parameters:
sags/dips, swells, frequency, harmonics, ...".  The parameters
considered in IEC 61000-4-30 include:  Power frequency,  Magntiude of
Supply Voltage,  Flicker,  Supply Dips/Swells, Voltage Interruptions,
Unbalance, Harmonics, Interharmonics,  Mains Signaling, Under- and
over-deviation, ...

The focus of EMAN is on reporting power quality measurements (measured
by some device/meter and we trust the values, allowing a margin of
measurement error using the concept of accuracy). The question is what
are the power quality measurements that are useful ? 

In that context, a data model that is given in IEC 61850-7-4  LN MMXU
(Total active power, Total reactive power, Total apparent power, power
factot, ...) has been reused - Page 57 of IEC 61850-7-4 Ed.2.0
Communication networks and systems for power utility automation - Part
7-4: Basic communication structure -Compatible logical node classes and
data object classes.

Thanks
Mouli

-----Original Message-----
From: Brad Schoening [mailto:[email-masked]] 
Sent: Monday, September 05, 2011 9:35 PM
To: Michael Suchoff; Juergen Quittek; Mouli Chandramouli (moulchan)
Cc: eman mailing list
Subject: RE: [eman] Comments on eman requirements

Hi Michael,

IEC 61000-4-30 appears to be a standard for benchmark measurement
methods and testing.  It does not seem to include a data model for
reporting and management over protocols such as IP or SNMP.  

Thanks,

Brad

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael Suchoff
Sent: Wednesday, July 13, 2011 11:39 AM
To: Juergen Quittek; Mouli Chandramouli (moulchan)
Cc: eman mailing list
Subject: Re: [eman] Comments on eman requirements

-----Original Message-----
From: Juergen Quittek [mailto:[email-masked]] 
Sent: Wednesday, July 13, 2011 8:59 AM
To: Mouli Chandramouli (moulchan)
Cc: Michael Suchoff; eman mailing list
Subject: Re: [eman] Comments on eman requirements

Hi Mouli,

Thanks,

    Juergen

which
and
there
Of
-
value
the
(joule/
relationship
chances
load.
the
time