Energy Management Framework
draft-ietf-eman-framework-12
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7326.
|
|
---|---|---|---|
Authors | John Parello , Benoît Claise , Brad Schoening , Juergen Quittek | ||
Last updated | 2014-01-11 | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews |
SECDIR Last Call review
(of
-15)
by Yoav Nir
Has issues
|
||
Additional resources | Mailing list discussion | ||
Stream | WG state | WG Document | |
Document shepherd | Thomas Nadeau | ||
IESG | IESG state | Became RFC 7326 (Informational) | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | Joel Jaeggli | ||
Send notices to | (None) |
draft-ietf-eman-framework-12
quot;. Claise et al. Expires October 11, 2015 [Page 17] Internet-Draft EMAN Framework January 2014 6.3.6. Context: Domain The Energy Object (Class) contains a string attribute to indicate membership in an Energy Management Domain. An Energy Management Domain can be any collection of Energy Objects in a deployment, but it is recommended to map 1:1 with a metered or sub-metered portion of the site. In building management, a meter refers to the meter provided by the utility used for billing and measuring power to an entire building or unit within a building. A sub-meter refers to a customer- or user-installed meter that is not used by the utility to bill but is instead used to get measurements from sub portions of a building. An Energy Object should be a member of a single Energy Management Domain therefore one attribute is provided. 6.4. Measurements The Energy Object (Class) contains attributes to describe power, energy and demand measurements. An analogy for understanding power versus energy measurements can be made to speed and distance in automobiles. Just as a speedometer indicates the rate of change of distance (speed), a power measurement indicates the rate of transfer of energy. The odometer in an automobile measures the cumulative distance traveled and similarly an energy measurement indicates the accumulated energy transferred. Demand measurements are averages of power measurements over time. So using the same analogy to an automobile: measuring the average vehicle speed over multiple intervals of time for a given distance travelled, demand is the average power measured over multiple time intervals for a given energy value. Within this framework, energy will only be quantified in units of watt-hours. Physical devices measuring energy in other units must convert values to watt-hours or be represented by Energy Objects that convert to watt-hours. 6.4.1. Measurements: Power The Energy Object (Class) contains a Nameplate Power attribute that describes the nominal power as specified by the manufacturer of the device. The EnMS can use the Claise et al. Expires October 11, 2015 [Page 18] Internet-Draft EMAN Framework January 2014 Nameplate Power for provisioning, capacity planning and (potentially) billing. The Energy Object (Class) has attributes that describe the present power information, along with how that measurement was obtained or derived (e.g., actual, estimated, or static). A power measurement is qualified with the units, magnitude and direction of power flow, and is qualified as to the means by which the measurement was made. Power measurement magnitude conforms to the [IEC61850] definition of unit multiplier for the SI (System International) units of measure. Measured values are represented in SI units obtained by BaseValue * (10 ^ Scale). For example, if current power usage of an Energy Object is 17, it could be 17 W, 17 mW, 17 kW, or 17 mW, depending on the value of the scaling factor. 17 W implies that the BaseValue is 17 and Scale = 0, whereas 17 mW implies BaseValue = 17 and ScaleFactor = -3. An Energy Object (Class) indicates how the power measurement was obtained with a caliber and accuracy attribute that indicates: o Whether the measurements were made at the device itself or at a remote source. o Description of the method that was used to measure the power and whether this method can distinguish actual or estimated values. o Accuracy for actual measured values 6.4.2. Measurements: Power Attributes The Energy Object (Class) contains an optional attribute that describes Power Attribute information reflecting the electrical characteristics of the measurement. These Power Attributes adhere to the [IEC-61850-7-2] standard for describing AC measurements. 6.4.3. Measurements: Energy The Energy Object (Class) contains optional attributes that represent the energy used, received, produced and or stored. Typically only devices or components that can measure actual power will have the ability to measure energy. Claise et al. Expires October 11, 2015 [Page 19] Internet-Draft EMAN Framework January 2014 6.4.4. Measurements: Demand The Energy Object (Class) contains optional attributes that represent demand information over time. Typically only devices or components that can report actual power are capable of measuring demand. 6.5. Control The Energy Object (Class) contains a Power State Set (Class) attribute that represents the set of Power States a device or component supports. A Power State describes a condition or mode of a device or component. While Power States are typically used for control they may be used for monitoring only. A device or component is expected to support at least one set of Power States consisting of at least two states, an on state and an off state. There are many existing standards describing device and component Power States. The framework supports modeling a mixed set of Power States defined in different standards. A basic example is given by the three Power States defined in IEEE1621 [IEEE1621]: on, off, and sleep. The DMTF [DMTF], ACPI [ACPI], and PWG all define larger numbers of Power States. The semantics of a Power State are specified by a) the functionality provided by an Energy Object in this state, b) a limitation of the power that an Energy Object uses in this state, c) a combination of a) and b) The semantics of a Power State should be clearly defined. Limitation (curtailment) of the power used by an Energy Object in a state may be specified by: o an absolute power value o a percentage value of power relative to the energy object's nameplate power o an indication of power relative to another power state. For example: Specify that power in state A is less than in state B. Claise et al. Expires October 11, 2015 [Page 20] Internet-Draft EMAN Framework January 2014 o For supporting Power State management an Energy Object provides statistics on Power States including the time an Energy Object spent in a certain Power State and the number of times an Energy Object entered a power state. When requesting an Energy Object to enter a Power State an indication of the Power State's name or number can be used. Optionally an absolute or percentage of Nameplate Power can be provided to allow the Energy Object to transition to a nearest or equivalent Power State. When an Energy Object is set to a particular Power State, the represented device or component may be busy. The Energy Object should set the desired Power State and then update the actual Power State when the device or component changes. There are then two Power State (Class) control attributes: actual and requested. The following sections describe well-known Power States for devices and components that should be modeled in the information model. 6.5.1. Power State Sets There are several standards and implementations of Power State Sets. The Energy Object (Class) support modeling one or multiple Power State Set implementation(s) on the device or component concurrently. There are currently three Power State Sets advocated: IEEE1621(256) - [IEEE1621] DMTF(512) - [DMTF] EMAN(768) - [this document] The respective specific states related to each Power State Set are specified in the following sections. The guidelines for the modification of Power State Sets are specified in the IANA Considerations Section. 6.5.2. Power State Set: IEEE1621 The IEEE1621 Power State Set [IEEE1621] consists of 3 rudimentary states: on, off or sleep. In IEEE1621 devices are limited to the three basic power states - on, sleep, and off. Any additional power states are variants of one of the basic states rather than a fourth state [IEEE1621]. Claise et al. Expires October 11, 2015 [Page 21] Internet-Draft EMAN Framework January 2014 6.5.3. Power State Set: DMTF The DMTF [DMTF] standards organization has defined a power profile standard based on the CIM (Common Information Model) model that consists of 15 power states: {ON (2), SleepLight (3), SleepDeep (4), Off-Hard (5), Off- Soft (6), Hibernate(7), PowerCycle Off-Soft (8), PowerCycle Off-Hard (9), MasterBus reset (10), Diagnostic Interrupt (11), Off-Soft-Graceful (12), Off-Hard Graceful (13), MasterBus reset Graceful (14), Power-Cycle Off-Soft Graceful (15), PowerCycle-Hard Graceful (16)} The DMTF standard is targeted for hosts and computers. Details of the semantics of each Power State within the DMTF Power State Set can be obtained from the DMTF Power State Management Profile specification [DMTF]. The DMTF power profile extends ACPI power states. The following table provides a mapping between DMTF and ACPI Power State Set: DMTF ACPI Reserved(0) Reserved(1) ON (2) G0-S0 Sleep-Light (3) G1-S1 G1-S2 Sleep-Deep (4) G1-S3 Power Cycle (Off-Soft) (5) G2-S5 Off-hard (6) G3 Hibernate (Off-Soft) (7) G1-S4 Off-Soft (8) G2-S5 Power Cycle (Off-Hard) (9) G3 Master Bus Reset (10) G2-S5 Diagnostic Interrupt (11) G2-S5 Off-Soft Graceful (12) G2-S5 Off-Hard Graceful (13) G3 MasterBus Reset Graceful (14) G2-S5 Power Cycle off-soft Graceful (15) G2-S5 Power Cycle off-hard Graceful (16) G3 6.5.4. Power State Set: IETF EMAN The EMAN Power States are an expansion of the basic Power States as defined in [IEEE1621] that also incorporates the Power States defined in [ACPI] and [DMTF]. Therefore, in addition to the non-operational states as defined in [ACPI] Claise et al. Expires October 11, 2015 [Page 22] Internet-Draft EMAN Framework January 2014 and [DMTF] standards, several intermediate operational states have been defined. Physical devices and components are expected to support the EMAN Power State Set or to be modeled via an Energy Object the supports these states. An Energy Object may implement fewer or more Power States than a particular EMAN Power State Set specifies. In that case, the Energy Object implementation can determine its own mapping to the predefined EMAN Power States within the EMAN Power State Set. There are twelve EMAN Power States that expand on [IEEE1621]. The expanded list of Power States is derived from [CISCO-EW] and is divided into six operational states and six non-operational states. The lowest non-operational state is 1 and the highest is 6. Each non-operational state corresponds to an [ACPI] Global and System state between G3 (hard-off) and G1 (sleeping). Each operational state represents a performance state, and may be mapped to [ACPI] states P0 (maximum performance power) through P5 (minimum performance and minimum power). In each of the non-operational states (from mechoff(1) to ready(6)), the Power State preceding it is expected to have a lower Power value and a longer delay in returning to an operational state: mechoff(1) : An off state where no Energy Object features are available. The Energy Object is unavailable. No energy is being consumed and the power connector can be removed. softoff(2) : Similar to mechoff(1), but some components remain powered or receive trace power so that the Energy Object can be awakened from its off state. In softoff(2), no context is saved and the device typically requires a complete boot when awakened. hibernate(3): No Energy Object features are available. The Energy Object may be awakened without requiring a complete boot, but the time for availability is longer than sleep(4). An example for state hibernate(3) is a save to-disk state where DRAM context is not maintained. Typically, energy consumption is zero or close to zero. Claise et al. Expires October 11, 2015 [Page 23] Internet-Draft EMAN Framework January 2014 sleep(4) : No Energy Object features are available, except for out-of-band management, such as wake- up mechanisms. The time for availability is longer than standby(5). An example for state sleep(4) is a save-to-RAM state, where DRAM context is maintained. Typically, energy consumption is close to zero. standby(5) : No Energy Object features are available, except for out-of-band management, such as wake- up mechanisms. This mode is analogous to cold-standby. The time for availability is longer than ready(6). For example processor context is may not be maintained. Typically, energy consumption is close to zero. ready(6) : No Energy Object features are available, except for out-of-band management, such as wake- up mechanisms. This mode is analogous to hot-standby. The Energy Object can be quickly transitioned into an operational state. For example, processors are not executing, but processor context is maintained. lowMinus(7) : Indicates some Energy Object features may not be available and the Energy Object has taken measures or selected options to use less energy than low(8). low(8) : Indicates some features may not be available and the Energy Object has taken measures or selected options to use less energy than mediumMinus(9). mediumMinus(9): Indicates all Energy Object features are available but the Energy Object has taken measures or selected options to use less energy than medium(10). medium(10) : Indicates all Energy Object features are available but the Energy Object has taken measures or selected options to use less energy than highMinus(11). highMinus(11): Indicates all Energy Object features are available and has taken measures or selected options to use less energy than high(12). high(12) : Indicates all Energy Object features are available and the Energy Object may use the maximum energy as indicated by the Nameplate Power. Claise et al. Expires October 11, 2015 [Page 24] Internet-Draft EMAN Framework January 2014 6.5.5. Power State Sets Comparison A comparison of Power States from different Power State Sets can be seen in the following table: IEEE1621 DMTF ACPI EMAN Non-operational states off Off-Hard G3, S5 MechOff(1) off Off-Soft G2, S5 SoftOff(2) off Hibernate G1, S4 Hibernate(3) sleep Sleep-Deep G1, S3 Sleep(4) sleep Sleep-Light G1, S2 Standby(5) sleep Sleep-Light G1, S1 Ready(6) Operational states: on on G0, S0, P5 LowMinus(7) on on G0, S0, P4 Low(8) on on G0, S0, P3 MediumMinus(9) on on G0, S0, P2 Medium(10) on on G0, S0, P1 HighMinus(11) on on G0, S0, P0 High(12) 6.6. Relationships The Energy Object (Class) contains a set of Relationship (Class) attributes to model the relationships between devices and components. Two Energy Objects can establish an Energy Object Relationship to model the deployment topology with respect to Energy Management. Relationships are modeled with a Relationship (Class) that contains the UUID of the other participant in the relationship and a name that describes the type of relationship [CHEN]. The types of relationships are: Power Source, Metering, and Aggregations. o A Power Source Relationship is relationship where one Energy Object provides power to one or more Energy Objects. The Power Source Relationship gives a view of the physical wiring topology. For example: a data center server receiving power from two specific Power Interfaces from two different PDUs. Claise et al. Expires October 11, 2015 [Page 25] Internet-Draft EMAN Framework January 2014 Note: A Power Source Relationship may or may not change as the direction of power changes between two Energy Objects. The relationship may remain to indicate the change of power direction was unintended or an error condition. o A Metering Relationship is relationship where one Energy Object measures power, energy, demand or Power Attributes of one or more other Energy Objects. The Metering Relationship gives the view of the metering topology. Physical meters can be placed anywhere in a power distribution tree. For example, utility meters monitor and report accumulated power consumption of the entire building. Logically, the metering topology overlaps with the wiring topology, as meters are connected to the wiring topology. A typical example is meters that clamp onto the existing wiring. o An Aggregation Relationship is a relationship where one Energy Object aggregates Energy Management information of one or more other Energy Objects. The Aggregation Relationship gives a model of devices that may aggregate (sum, average, etc) values for other devices. The Aggregation Relationship is slightly different compared to the other relationships as this refers more to a management function. In some situations, it is not possible to discover the Energy Object relationships, and an EnMS or administrator must set them. Given that relationships can be assigned manually, the following sections describe guidelines for use. 6.6.1. Relationship Conventions and Guidelines This Energy Management framework does not impose many "MUST" rules related to Energy Object Relationships. There are always corner cases that could be excluded with too strict specifications of relationships. However, the framework proposes a series of guidelines, indicated with "SHOULD" and "MAY". 6.6.2. Guidelines: Power Source Power Source relationships are intended to identify the connections between Power Interfaces. This is analogous to Claise et al. Expires October 11, 2015 [Page 26] Internet-Draft EMAN Framework January 2014 a Layer 2 connection in networking devices (a "one-hop connection"). The preferred modeling would be for Power Interfaces to participate in Power Source Relationships. It some cases Energy Objects may not have the capability to model Power Interfaces. Therefore a Power Source Relationship can be established between two Energy Objects or two non-connected Power Interfaces. While strictly speaking Components and Power Interfaces on the same Device do provide or receive energy from each other, the Power Source relationship is intended to show energy transfer between Devices. Therefore the relationship is implied when on the same Device. An Energy Object SHOULD NOT establish a Power Source Relationship with a Component. o A Power Source Relationship SHOULD be established with the next known Power Interface in the wiring topology. o The next known Power Interface in the wiring topology would be the next device implementing the framework. In some cases the domain of devices under management may include some devices that do not implement the framework. In these cases, the Power Source relationship can be established with the next device in the topology that implements the framework and logically shows the Power Source of the device. o Transitive Power Source relationships SHOULD NOT be established. For example, if an Energy Object A has a Power Source Relationship "Poweredby" with the Energy Object B, and if the Energy Object B has a Power Source Relationship "Poweredby" with the Energy Object C, then the Energy Object A SHOULD NOT have a Power Source Relationship "Poweredby" with the Energy Object C. 6.6.3. Guidelines: Metering Relationship Metering Relationships are intended to show when one device acting as a meter is measuring the power or energy at a point in a power distribution system. Since one point of a power distribution system may cover many devices within a wiring topology, this relationship type can be seen as a set. Claise et al. Expires October 11, 2015 [Page 27] Internet-Draft EMAN Framework January 2014 Some devices, however, may include measuring hardware for components, and outlets or for the entire device. For example, some PDUs may have the ability to measure power for each outlet and are commonly referred to as metered-by- outlet. Others may be able to control power at each power outlet but can only measure power at the power inlet - commonly referred to as metered-by-device. While the Metering Relationship could be used to represent a device as metered-by-outlet or metered-by-device, the Metering Relationship SHOULD be used to model the relationship between a meter and all devices covered by the meter downstream in the power distribution system In general: o A Metering Relationship MAY be established with any other Energy Object, Component, or Power Interface. o Transitive Metering Relationships MAY be used. o When there is a series of meters for one Energy Object, the Energy Object MAY establish a Metering relationship with one or more of the meters. 6.6.4. Guidelines: Aggregation Aggregation relationships are intended to identify when one device is used to accumulate values from other devices. Typically this is for energy or power values among devices and not for Components or Power Interfaces on the same device. The intent of Aggregation relationships is to indicate when one device is providing aggregate values for a set of other devices when it is not obvious from the power source or simple containment within a device. Establishing aggregation relationships within the same device would make modeling more complex and the aggregated values can be implied from the use of Power Inlets, outlet and Energy Object values on the same device. Since an EnMS is naturally a point of aggregation it is not necessary to model aggregation for Energy Management Systems. The Aggregation Relationship is intended for power and energy. It MAY be used for aggregation of other values from Claise et al. Expires October 11, 2015 [Page 28] Internet-Draft EMAN Framework January 2014 the information model, but the rules and logical ability to aggregate each attribute is out of scope for this document. In general: o A Device SHOULD NOT establish an Aggregation Relationship with Components contained on the same device. o A Device SHOULD NOT establish an Aggregation Relationship with the Power Interfaces contained on the same device. o A Device SHOULD NOT establish an Aggregation Relationship with an EnMS. o Aggregators SHOULD log or provide notification in the case of errors or missing values while performing aggregation. 6.6.5. Energy Object Relationship Extensions This framework for Energy Management is based on three relationship types: Aggregation , Metering, and Power Source. This framework is defined with possible future extension of new Energy Object Relationships in mind. For example: o Some Devices that may not be IP connected. This can be modeled with a proxy relationship to an Energy Object within the domain. This type of proxy relationship is left for further development. o A Power Distribution Unit (PDU) that allows devices and components like outlets to be "ganged" together as a logical entity for simplified management purposes, could be modeled with an extension called a "gang relationship", whose semantics would specify the Energy Objects' grouping. 7. Energy Management Information Model This section presents an information model expression of the concepts in this framework as a reference for implementers. The information model is implemented as a MIB in the different related IETF EMAN documents. However, other programming structures with different data models could be used as well. Data modeling specifications of this information model may where needed specify which attributes are required or optional. Claise et al. Expires October 11, 2015 [Page 29] Internet-Draft EMAN Framework January 2014 Syntax UML Construct [ISO-IEC-19501-2005] Equivalent Notation -------------------- ------------------------------------ Notes // Notes Class (Generalization) CLASS name {member..} Sub-Class (Specialization) CLASS subclass EXTENDS superclass {member..} Class Member (Attribute) attribute : type Model CLASS EnergyObject { // identification / classification index : int identifier : uuid alternatekey : string // context domainName : string role : string keywords [0..n] : string importance : int // relationship relationships [0..n] : Relationship // measurements nameplate : Nameplate power : PowerMeasurement energy : EnergyMeasurment demand : DemandMeasurement // control powerControl [0..n] : PowerStateSet } Claise et al. Expires October 11, 2015 [Page 30] Internet-Draft EMAN Framework January 2014 CLASS PowerInterface EXTENDS EnergyObject{ eoIfType : enum { inlet, outlet, both} } CLASS Device EXTENDS EnergyObject { eocategory : enum { producer, consumer, meter, distributor, store } powerInterfaces[0..n]: PowerInterface components [0..n] : Component } CLASS Component EXTENDS EnergyObject eocategory : enum { producer, consumer, meter, distributor, store } powerInterfaces[0..n]: PowerInterface components [0..n] : Component } CLASS Nameplate { nominalPower : PowerMeasurement details : URI } CLASS Relationship { relationshipType : enum { meters, meteredby, powers, poweredby, aggregates, aggregatedby } relationshipObject : uuid } CLASS Measurement { multiplier: enum { -24..24} caliber : enum { actual, estimated, static } accuracy : enum { 0..10000} // hundreds of percent } CLASS PowerMeasurement EXTENDS Measurement { value : long units : "W" powerAttribute : PowerAttribute } CLASS EnergyMeasurement EXTENDS Measurement { startTime : time units : "kWh" provided : long used : long produced : long Claise et al. Expires October 11, 2015 [Page 31] Internet-Draft EMAN Framework January 2014 stored : long } CLASS TimedMeasurement EXTENDS Measurement { startTime : timestamp value : Measurement maximum : Measurement } CLASS TimeInterval { value : long units : enum { seconds, miliseconds,...} } CLASS DemandMeasurement EXTENDS Measurement { intervalLength : TimeInterval intervals : long intervalMode : enum { periodic, sliding, total } intervalWindow : TimeInterval sampleRate : TimeInterval status : enum { active, inactive } measurements[0..n] : TimedMeasurements } CLASS PowerStateSet { powerSetIdentifier : int name : string powerStates [0..n] : PowerState operState : int adminState : int reason : string configuredTime : timestamp } CLASS PowerState { powerStateIdentifier : int name : string cardinality : int maximumPower : PowerMeasurement totalTimeInState : time entryCount : long } CLASS PowerAttribute { acQuality : ACQuality } CLASS ACQuality { acConfiguration : enum {SNGL, DEL,WYE} Claise et al. Expires October 11, 2015 [Page 32] Internet-Draft EMAN Framework January 2014 avgVoltage : long avgCurrent : long frequency : long unitMultiplier : int accuracy : int totalActivePower : long totalReactivePower : long totalApparentPower : long totalPowerFactor : long phases [0..2] : ACPhase } CLASS ACPhase { phaseIndex : long avgCurrent : long activePower : long reactivePower : long apparentPower : long powerFactor : long } CLASS DelPhase EXTENDS ACPhase { phaseToNextPhaseVoltage : long thdVoltage : long thdCurrent : long } CLASS WYEPhase EXTENDS ACPhase { phaseToNeutralVoltage : long thdCurrent : long thdVoltage : long } 8. Modeling Relationships between Devices In this section we give examples of how to use the EMAN information model to model physical topologies. Where applicable, we show how the framework can be applied when devices can be modeled with Power Interfaces. We also show how the framework can be applied when devices cannot be modeled with Power Interfaces but only monitored or control as a whole. For instance, a PDU may only be able to measure power and energy for the entire unit without the ability to distinguish among the inlets or outlets. 8.1. Power Source Relationship The Power Source relationship is used to model the interconnections between devices, components and/Power Claise et al. Expires October 11, 2015 [Page 33] Internet-Draft EMAN Framework January 2014 Interfaces to indicate the source of energy for a device. In the following examples we show variations on modeling the reference topologies using relationships. Given for all cases: Device W: A computer with one power supply. Power Interface 1 is an inlet for Device W. Device X: A computer with two power supplies. Power Interface 1 and power interface 2 are both inlets for Device X. Device Y: A PDU with multiple Power Interfaces numbered 0..10. Power Interface 0 is an inlet and Power Interface 1..10 are outlets. Device Z: A PDU with multiple Power Interfaces numbered 0..10. Power Interface 0 is an inlet and Power Interface 1..10 are outlets. Case 1: Simple Device with one Source Physical Topology: o Device W inlet 1 is plugged into Device Y outlet 8. With Power Interfaces: o Device W has an Energy Object representing the computer itself as well as one Power Interface defined as an inlet. o Device Y would have an Energy Object representing the PDU itself (the Device), with a Power Interface 0 defined as an inlet and Power Interfaces 1..10 defined as outlets. The interfaces of the devices would have a Power Source Relationship such that: Device W inlet 1 is powered by Device Y outlet 8. +-------+------+ poweredBy +------+----------+ | PDU Y | PI 8 |-----------------| PI 1 | Device W | +-------+------+ powers +------+----------+ Without Power Interfaces: Claise et al. Expires October 11, 2015 [Page 34] Internet-Draft EMAN Framework January 2014 o Device W has an Energy Object representing the computer. o Device Y would have an Energy Object representing the PDU. The devices would have a Power Source Relationship such that: Device W is powered by Device Y. +----------+ poweredBy +------------+ | PDU Y |-----------------| Device W | +----------+ powers +------------+ Case 2: Multiple Inlets Physical Topology: o Device X inlet 1 is plugged into Device Y outlet 8. o Device X inlet 2 is plugged into Device Y outlet 9. With Power Interfaces: o Device X has an Energy Object representing the computer itself. It contains two Power Interfaces defined as inlets. o Device Y would have an Energy Object representing the PDU itself (the Device), with a Power Interface 0 defined as an inlet and Power Interfaces 1..10 defined as outlets. The interfaces of the devices would have a Power Source Relationship such that: Device X inlet 1 is powered by Device Y outlet 8. Device X inlet 2 is powered by Device Y outlet 9. +-------+------+ poweredBy+------+----------+ | | PI 8 |-----------------| PI 1 | | | | |powers | | | | PDU Y +------+ poweredBy+------+ Device X | | | PI 9 |-----------------| PI 2 | | | | |powers | | | +-------+------+ +------+----------+ Without Power Interfaces: Claise et al. Expires October 11, 2015 [Page 35] Internet-Draft EMAN Framework January 2014 o Device X has an Energy Object representing the computer. Device Y has an Energy Object representing the PDU. The devices would have a Power Source Relationship such that: Device X is powered by Device Y. +----------+ poweredBy +------------+ | PDU Y |-----------------| Device X | +----------+ powers +------------+ Case 3: Multiple Sources Physical Topology: o Device X inlet 1 is plugged into Device Y outlet 8. o Device X inlet 2 is plugged into Device Z outlet 9. With Power Interfaces: o Device X has an Energy Object representing the computer itself. It contains two Power Interface defined as inlets. o Device Y would have an Energy Object representing the PDU itself (the Device), with a Power Interface 0 defined as an inlet and Power Interfaces 1..10 defined as outlets. o Device Z would have an Energy Object representing the PDU itself (the Device), with a Power Interface 0 defined as an inlet and Power Interfaces 1..10 defined as outlets. The interfaces of the devices would have a Power Source Relationship such that: Device X inlet 1 is powered by Device Y outlet 8. Device X inlet 2 is powered by Device Z outlet 9. +-------+------+ poweredBy+------+----------+ | PDU Y | PI 8 |-----------------| PI 1 | | | | |powers | | | +-------+------+ +------+ | | Device X | +-------+------+ poweredBy+------+ | | PDU Z | PI 9 |-----------------| PI 2 | | | | |powers | | | +-------+------+ +------+----------+ Claise et al. Expires October 11, 2015 [Page 36] Internet-Draft EMAN Framework January 2014 Without Power Interfaces: o Device X has an Energy Object representing the computer. Device Y and Z would both have respective Energy Objects representing each entire PDU. The devices would have a Power Source Relationship such that: Device X is powered by Device Y and powered by Device Z. +----------+ poweredBy +------------+ | PDU Y |---------------------| Device X | +----------+ powers +------------+ +----------+ poweredBy +------------+ | PDU Z |---------------------| Device X | +----------+ powers +------------+ 8.2. Metering Relationship A meter in a power distribution system can logically measure the power or energy for all devices downstream from the meter in the power distribution system. As such, a Metering relationship can be seen as a relationship between a meter and all of the devices downstream from the meter. We define in this case a Metering relationship between a meter and devices downstream from the meter. +-----+---+ meteredBy +--------+ poweredBy +-------+ |Meter| PI|--------------| switch |-------------| phone | +-----+---+ meters +--------+ powers +-------+ | | | meteredBy | +-------------------------------------------+ meters In cases where the Power Source topology cannot be discovered or derived from the information available in the Energy Management Domain, the metering topology can be used to relate the upstream meter to the downstream devices in the absence of specific Power Source relationships. A Metering Relationship can occur between devices that are not directly connected, as shown in the following figure: +---------------+ Claise et al. Expires October 11, 2015 [Page 37] Internet-Draft EMAN Framework January 2014 | Device 1 | +---------------+ | PI | +---------------+ | +---------------+ | Meter | +---------------+ . . . meters meters meters +----------+ +----------+ +-----------+ | Device A | | Device B | | Device C | +----------+ +----------+ +-----------+ An analogy to communications networks would be modeling connections between servers (meters) and clients (devices) when the complete Layer 2 topology between the servers and clients is not known. 8.3. Aggregation Relationship Some devices can act as aggregation points for other devices. For example, a PDU controller device may contain the summation of power and energy readings for many PDU devices. The PDU controller will have aggregate values for power and energy for a group of PDU devices. This aggregation is independent of the physical power or communication topology. The functions that the aggregation point may perform include the calculation of values such as average, count, maximum, median, minimum, or the listing (collection) of the aggregation values, etc. Based on the experience gained on aggregations at the IETF [draft-ietf-ipfix-a9n-08], the aggregation function in the EMAN framework is limited to the summation. When aggregation occurs across a set of entities, values to be aggregated may be missing for some entities. The EMAN framework does not specify how these should be treated, as different implementations may have good reason to take different approaches. One common treatment is to define the aggregation as missing if any of the constituent elements are missing (useful to be most precise). Another is to treat the missing value as zero (useful to have continuous data streams). Claise et al. Expires October 11, 2015 [Page 38] Internet-Draft EMAN Framework January 2014 The specifications of aggregation functions are out of scope of the EMAN framework, but must be clearly specified by the equipment vendor. 9. Relationship to Other Standards This Energy Management framework uses, as much as possible, existing standards especially with respect to information modeling and data modeling [RFC3444]. The data model for power- and energy-related objects is based on [IEC61850]. Specific examples include: o The scaling factor, which represents Energy Object usage magnitude, conforms to the [IEC61850] definition of unit multiplier for the SI (System International) units of measure. o The electrical characteristic is based on the ANSI and IEC Standards, which require that we use an accuracy class for power measurement. ANSI and IEC define the following accuracy classes for power measurement: o IEC 62053-22 60044-1 class 0.1, 0.2, 0.5, 1 3. o ANSI C12.20 class 0.2, 0.5 o The electrical characteristics and quality adhere closely to the [IEC61850-7-4] standard for describing AC measurements. o The power state definitions are based on the DMTF Power State Profile and ACPI models, with operational state extensions. 10. Implementation Status [Note to RFC Editor: Please remove this section and the reference to [RFC6982] before publication.] This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in RFC6982. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of Claise et al. Expires October 11, 2015 [Page 39] Internet-Draft EMAN Framework January 2014 available implementations or their features. Readers are advised to note that other implementations may exist. According to RFC 6982, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. Implementation descriptions for this document are maintained at: http://tools.ietf.org/wg/eman/trac/wiki/EmanImplementations 11. Security Considerations Regarding the data attributes specified here, some or all may be considered sensitive or vulnerable in some network environments. Reading or writing these attributes without proper protection such as encryption or access authorization may have negative effects on network capabilities. The information and control capabilities specified in this framework could be exploited with detriment to a site or deployment. Implementers of the framework SHOULD examine and mitigate security threats with respect to these new capabilities. [RFC3410] User Security Model for SNMPv3 presents a good description of threats and mitigations for the SNMPv3 protocol that can be used as a guide for implementations of this framework using other protocols. 11.1. Security Considerations for SNMP Readable objects in MIB modules (i.e., objects with a MAX- ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is important to control GET and/or NOTIFY access to these objects and possibly to encrypt the values of these objects when sending them over the network via SNMP. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. For example: Claise et al. Expires October 11, 2015 [Page 40] Internet-Draft EMAN Framework January 2014 o Unauthorized changes to the Energy Management Domain or business context of a device may result in misreporting or interruption of power. o Unauthorized changes to a power state may disrupt the power settings of the different devices, and therefore the state of functionality of the respective devices. o Unauthorized changes to the demand history may disrupt proper accounting of energy usage. With respect to data transport, SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example, by using IPsec), there is still no secure control over who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in these MIB modules. It is recommended that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is not recommended. Instead, it is recommended to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of these MIB modules is properly configured to give access to the objects only to those principals (users) that have legitimate rights to GET or SET (change/create/delete) them. 12. IANA Considerations 12.1. IANA Registration of new Power State Sets This document specifies an initial set of Power State Sets. The list of these Power State Sets with their numeric identifiers is given is Section 6. IANA maintains the lists of Power State Sets. New assignments for Power State Set are administered by IANA through Expert Review [RFC5226], i.e., review by one of a group of experts designated by an IETF Area Director. The group of experts MUST check the requested state for completeness and accuracy of the description. A pure vendor specific implementation of Power State Set shall not be Claise et al. Expires October 11, 2015 [Page 41] Internet-Draft EMAN Framework January 2014 adopted; since it would lead to proliferation of Power State Sets. Power states in a Power State Set are limited to 255 distinct values. New Power State Set must be assigned the next available numeric identifier that is a multiple of 256. 12.1.1. IANA Registration of the IEEE1621 Power State Set This document specifies a set of values for the IEEE1621 Power State Set [IEEE1621]. The list of these values with their identifiers is given in Section 6.6.2. IANA created a new registry for IEEE1621 Power State Set identifiers and filled it with the initial list of identifiers. New assignments (or potentially deprecation) for the IEEE1621 Power State Set is administered by IANA through Expert Review [RFC5226], i.e., review by one of a group of experts designated by an IETF Area Director. The group of experts must check the requested state for completeness and accuracy of the description. 12.1.2. IANA Registration of the DMTF Power State Set This document specifies a set of values for the DMTF Power State Set. The list of these values with their identifiers is given in Section 6. IANA has created a new registry for DMTF Power State Set identifiers and filled it with the initial list of identifiers. New assignments (or potentially deprecation) for the DMTF Power State Set is administered by IANA through Expert Review [RFC5226], i.e., review by one of a group of experts designated by an IETF Area Director. The group of experts must check the conformance with the DMTF standard [DMTF], on the top of checking for completeness and accuracy of the description. 12.1.3. IANA Registration of the EMAN Power State Set This document specifies a set of values for the EMAN Power State Set. The list of these values with their identifiers is given in Section 6.6.4. IANA has created a new registry for EMAN Power State Set identifiers and filled it with the initial list of identifiers. New assignments (or potentially deprecation) for the EMAN Power State Set is administered by IANA through Expert Claise et al. Expires October 11, 2015 [Page 42] Internet-Draft EMAN Framework January 2014 Review [RFC5226], i.e., review by one of a group of experts designated by an IETF Area Director. The group of experts must check the requested state for completeness and accuracy of the description. 12.1.4. Batteries Power State Set Batteries have operational and administrational states that could be represented as a Power State Set. Since the work for battery management is parallel to this document, we are not proposing any Power State Sets for batteries at this time. 12.2. Updating the Registration of Existing Power State Sets With the evolution of standards, over time, it may be important to deprecate some of the existing the Power State Sets, or to add or deprecate some Power States within a Power State Set. The registrant shall publish an Internet-draft or an individual submission with the clear specification on deprecation of Power State Sets or Power States registered with IANA. The deprecation or addition shall be administered by IANA through Expert Review [RFC5226], i.e., review by one of a group of experts designated by an IETF Area Director. The process should also allow for a mechanism for cases where others have significant objections to claims on deprecation of a registration. 13. References Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet Standard Management Framework ", RFC 3410, December 2002 [RFC4122] Leach, P., Mealling, M., and R. Salz," A Universally Unique Identifier (UUID) URN Namespace", RFC 4122, July 2005 Claise et al. Expires October 11, 2015 [Page 43] Internet-Draft EMAN Framework January 2014 [RFC5226] Narten, T., and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, May 2008 [RFC6933] Bierman, A. and K. McCloghrie, "Entity MIB (Version4)", RFC 6933, May 2013 [RFC3444] Pras, A., Schoenwaelder, J. "On the Differences between Information Models and Data Models", RFC 3444, January 2003 [ISO-IEC-19501-2005] ISO/IEC 19501:2005, Information technology, Open Distributed Processing -- Unified Modeling Language (UML), January 2005 Informative References [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2", RFC 2578, April 1999 [RFC5101bis] Claise, B., Ed., and Trammel, T., Ed., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information ", draft-ietf-ipfix-protocol- rfc5101bis-08, (work in progress), June 2013 [RFC6020] M. Bjorklund, Ed., " YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010 [RFC3986] T. Berners-Lee, Ed., " Uniform Resource Identifier (URI): Generic Syntax", RFC3 986, January 2005 [ACPI] "Advanced Configuration and Power Interface Specification", http://www.acpi.info/spec30b.htm [IEEE1621] "Standard for User Interface Elements in Power Control of Electronic Devices Employed in Office/Consumer Environments", IEEE 1621, December 2004 [LLDP] IEEE Std 802.1AB, "Station and Media Control Connectivity Discovery", 2005 Claise et al. Expires October 11, 2015 [Page 44] Internet-Draft EMAN Framework January 2014 [LLDP-MED-MIB] ANSI/TIA-1057, "The LLDP Management Information Base extension module for TIA-TR41.4 media endpoint discovery information", July 2005 [EMAN-REQ] Quittek, J., Winter, R., Dietz, T., Claise, B., and M. Chandramouli, "Requirements for Energy Management", draft-ietf-eman-requirements-14, (work in progress), May 2013 [EMAN-OBJECT-MIB] Parello, J., and B. Claise, "Energy Object Contet MIB", draft-ietf-eman-energy-aware- mib-08, (work in progress), April 2013 [EMAN-MON-MIB] Chandramouli, M.,Schoening, B., Quittek, J., Dietz, T., and B. Claise, "Power and Energy Monitoring MIB", draft-ietf-eman-energy- monitoring-mib-05, (work in progress), April 2013 [EMAN-BATTERY-MIB] Quittek, J., Winter, R., and T. Dietz, " Definition of Managed Objects for Battery Monitoring", draft-ietf-eman-battery-mib-08, (work in progress), February 2013 [EMAN-AS] Schoening, B., Chandramouli, M., and B. Nordman, "Energy Management (EMAN) Applicability Statement", draft-ietf-eman-applicability- statement-03, (work in progress), April 2013 [ITU-T-M-3400] TMN Recommendation on Management Functions (M.3400), 1997 [NMF] "Network Management Fundamentals", Alexander Clemm, ISBN: 1-58720-137-2, 2007 [TMN] "TMN Management Functions : Performance Management", ITU-T M.3400 [IEEE100] "The Authoritative Dictionary of IEEE Standards Terms" http://ieeexplore.ieee.org/xpl/mostRecentIssue.js p?punumber=4116785 [ISO50001] "ISO 50001:2011 Energy management systems - Requirements with guidance for use", http://www.iso.org/ [IEC60050] International Electrotechnical Vocabulary http://www.electropedia.org/iev/iev.nsf/welcome?o penform Claise et al. Expires October 11, 2015 [Page 45] Internet-Draft EMAN Framework January 2014 [IEC61850] Power Utility Automation, http://www.iec.ch/smartgrid/standards/ [IEC61850-7-4] Abstract communication service interface (ACSI), http://www.iec.ch/smartgrid/standards/ [IEEE-802.3at] IEEE 802.3 Working Group, "IEEE Std 802.3at- 2009 - IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications - Amendment: Data Terminal Equipment (DTE) - Power via Media Dependent Interface (MDI) Enhancements", October 2009 [DMTF] "Power State Management Profile DMTF DSP1027 Version 2.0" December 2009 http://www.dmtf.org/sites/default/files/standards /documents/DSP1027_2.0.0.pdf [IPENERGY] R. Aldrich, J. Parello "IP-Enabled Energy Management", 2010, Wiley Publishing [X.700] CCITT Recommendation X.700 (1992), Management framework for Open Systems Interconnection (OSI) for CCITT applications [ASHRAE-201] "ASHRAE Standard Project Committee 201 (SPC 201)Facility Smart Grid Information Model", http://spc201.ashraepcs.org [CHEN] "The Entity-Relationship Model: Toward a Unified View of Data", Peter Pin-shan Chen, ACM Transactions on Database Systems, 1976 [CISCO-EW] "Cisco EnergyWise Design Guide", John Parello, Roland Saville, Steve Kramling, Cisco Validated Designs, September 2010, http://www.cisco.com/en/US/docs/solutions/Enterpr ise/Borderless_Networks/Energy_Management/energyw isedg.html Claise et al. Expires October 11, 2015 [Page 46] Internet-Draft EMAN Framework January 2014 14. Acknowledgments The authors would like to thank Michael Brown for his editorial work improving the text dramatically. Thanks to Rolf Winter for his feedback and to Bill Mielke for feedback and very detailed review. Thanks to Bruce Nordman for brainstorming with numerous conference calls and discussions. Finally, the authors would like to thank the EMAN chairs: Nevil Brownlee, Bruce Nordman, and Tom Nadeau. This document was prepared using 2-Word-v2.0.template.dot. Appendix A. Information Model Listing EnergyObject (Class) r index Integer An RFC6933 entPhysicalIndex w name String An RFC6933 entPhysicalName r identifier uuid An [RFC6933] entPhysicalUUID rw alternatekey String A manufacturer defined string that can be used to identify the Energy Object rw domainName String The name of an Energy Management domain for the Energy Object rw role String An administratively assigned name to indicate the purpose an Energy Object serves in the network rw keywords String A list of keywords or [0..n] tags that can be used to group Energy Objects for reporting or searching rw importance Integer Specifies a ranking of how important the Energy Object is (on a Claise et al. Expires October 11, 2015 [Page 47] Internet-Draft EMAN Framework January 2014 scale of 1 to 100) compared with other Energy Objects rw relationships Relationship A list of [0..n] relationships between this Energy Object and other Energy Objects r nameplate Nameplate The nominal PowerMeasurement of the Energy Object as specified by the device manufacturer r power PowerMeasurement The present power measurement of the Energy Object r energy EnergyMeasurment The present energy measurement for the Energy Object r demand DemandMeasurement The present demand measurement for the Energy Object r powerControl PowerStateSet A list of Power States [0..n] Sets the Energy Object supports PowerInterface (Class) inherits from and specializes EnergyObject r eoIfType Enumeration Indicates if the Power Interface is an - inlet; outlet; both Claise et al. Expires October 11, 2015 [Page 48] Internet-Draft EMAN Framework January 2014 Device (Class) inherits from and specializes EnergyObject rw eocategory Enumeration Broadly indicates if the Device is a producer consumer meter distributor or store of energy r powerInterfaces PowerInterface A list of [0..n] PowerInterfaces contained in this Device r components Component A list of Components [0..n] contained in this Device Component (Class) inherits from and specializes EnergyObject rw eocategory Enumeration Broadly indicates if the Component is a producer consumer meter distributor or store of energy r powerInterfaces PowerInterface A list of [0..n] PowerInterfaces contained in this Component r components Component A list of Components [0..n] contained in this Component Claise et al. Expires October 11, 2015 [Page 49] Internet-Draft EMAN Framework January 2014 Nameplate (Class) r nominalPower PowerMeasurement The nominal power of the Energy Object as specified by the device manufacturer rw details URI an [RFC3986] URI that links to manufacturer information about the nominal power of a device Relationship (Class) rw relationshipType Enumeration A description of the relationhip indicating - meters; meteredby; powers; poweredby; aggregates; aggregatedby rw relationshipObject uuid An [RFC6933] entPhysicalUUID that indicates the other participating Energy Object in the relationship Measurement (Class) r multiplier Enumeration The magnitude of the Measurement in the range - 24..24 r caliber Enumeration Specifies how the Measurement was obtained - actual; estimated; static r accuracy Enumeration Specifies the accuracy of the measurement if applicable as 0..10000 indicating hundreds of percent Claise et al. Expires October 11, 2015 [Page 50] Internet-Draft EMAN Framework January 2014 PowerMeasurement (Class) inherits from and specializes Measurement r value Long A measurement value of power r units "W" The units of measure for the power - "Watts" r powerAttribute PowerAttribute Measurement of the electrical current; voltage; phase and/or frequencies for the PowerMeasurement EnergyMeasurement (Class) inherits from and specializes Measurement r startTime Time Specifies the start time of the EnergyMeasurement interval r units "kWh" The units of measure for the energy - kilowatt hours r provided Long A measurement of energy provided r used Long A measurement of energy used / consumed r produced Long A measurement of energy produced r stored Long A measurement of energy stores TimedMeasurement (Class) inherits from and specializes Measurement r startTime timestamp A start time of a measurement r value Measurement A measurement value r maximum Measurement A maximum value measured since a Claise et al. Expires October 11, 2015 [Page 51] Internet-Draft EMAN Framework January 2014 previous timestamp TimeInterval (Class) r value Long a value of time r units Enumeration a magnitude of time express as seconds with an SI prefix (miliseconds etc) DemandMeasurement (Class) inherits from and specializes Measurement rw intervalLength TimeInterval The length of time over which to compute average energy rw intervals Long The number of intervals that can be measured rw intervalMode Enumeration The mode of interval measurement as - periodic; sliding; total rw intervalWindow TimeInterval The duration between the starting time of one sliding window and the next starting time rw sampleRate TimeInterval The sampling rate at which to poll power in order to compute demand rw status Enumeration a control to start or stop demand measurement as - active; inactive r measurements[0 TimedMeasurement a collection of ..n] TimedMeasurements to compute demand Claise et al. Expires October 11, 2015 [Page 52] Internet-Draft EMAN Framework January 2014 PowerStateSet (Class) r powerSetIdentifier Integer an IANA assigned value indicating a Power State Set r name String A Power State Set name r powerStates [0..n] PowerState a set of Power States for the given identifier rw operState Integer The current operational Power State rw adminState Integer The desired Power State rw reason String Describes the reason for the adminState r configuredTime timestamp Indicates the time of the desired Power State PowerState (Class) r powerStateIdentifier Integer an IANA assigned value indicating a Power State r name String A name for the Power State r cardinality Integer A value indicating an ordering of the Power State rw maximumPower PowerMea indicates the maximum surement power for the Energy Object at this Power State r totalTimeInState Time Indicates the total time an Energy Object has been in this Power State since last reset r entryCount Long Indicates the number of time the Energy Object Claise et al. Expires October 11, 2015 [Page 53] Internet-Draft EMAN Framework January 2014 has entered changed to this state PowerAttribute (Class) r acQuality ACQuality Describes AC Power Attributes for a Measurement ACQuality (Class) r acConfiguration Enumera Describes the physical tion configuration of alternating current as single phase (SNGL) three phase delta (DEL) or three phase Y (WYE) r avgVoltage Long The average of the voltage measured over an integral number of AC cycles [IEC61850-7-4] 'Vol' r avgCurrent Long The current per phase [IEC61850-7-4] 'Amp' r frequency Long Basic frequency of the AC circuit [IEC61850-7-4] 'Hz' r unitMultiplier Integer Magnitude of watts for the usage value in this instance r accuracy Integer Percentage value in 100ths of a percent representing the presumed accuracy of active; reactive; and apparent power in this instance r totalActivePower Long A measured value of the actual power delivered to or consumed by the load [IEC61850-7-4] 'TotW' r totalReactivePower Long A measured value of the reactive portion of the apparent power [IEC61850-7- Claise et al. Expires October 11, 2015 [Page 54] Internet-Draft EMAN Framework January 2014 4] 'TotVAr' r totalApparentPower Long A measured value of the voltage and current which determines the apparent power as the vector sum of real and reactive power [IEC61850-7-4] 'TotVA' r totalPowerFactor Long A measured value of the ratio of the real power flowing to the load versus the apparent power [IEC61850-7-4] 'TotPF' r phases [0..2] ACPhase A description of the three phase power ACPhase (Class) r phaseIndex Long A phase angle typically corresponding to - 0; 120; 240 r avgCurrent Long A measured value of the current per phase [IEC61850-7-4] 'A' r activePower Long A measured value of the actual power delivered to or consumed by the load [IEC61850-7-4] 'W' r reactivePower Long A measured value of the reactive portion of the apparent power [IEC 61850-7-4] 'VAr' r apparentPower Long A measured value of the active plus reactive power [IEC61850-7-4] 'VA' r powerFactor Long A measure ratio of the real power flowing to the load versus the apparent power for this phase [IEC61850-7-4] 'PF' Claise et al. Expires October 11, 2015 [Page 55] Internet-Draft EMAN Framework January 2014 DelPhase (Class) inherits from and specializes ACPhase r phaseToNextPhase Long A measured value of phase to next Voltage phase voltages where the next phase is [IEC61850-7-4] 'PPV' r thdVoltage Long A calculated value for the voltage total harmonic disortion for phase to next phase. Method of calculation is not specified [IEC61850-7-4] 'ThdPPV' r thdCurrent Long A calculated value for the voltage total harmonic disortion (THD) for phase to phase. Method of calculation is not specified [IEC61850-7-4] 'ThdPPV' WYEPhase (Class) inherits from and specializes ACPhase r phaseToNeutral Long A measured value of phase to Voltage neutral voltage [IEC61850-7-4] 'PhV' r thdCurrent Long A measured value of phase currents [IEC 61850-7-4] 'A' r thdVoltage Long A calculated value of the voltage total harmonic distortion (THD) for phase to neutral [IEC61850-7- 4] 'ThdPhV' Authors' Addresses John Parello Cisco Systems, Inc. 3550 Cisco Way San Jose, California 95134 US Phone: +1 408 525 2339 Email: jparello@cisco.com Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Claise et al. Expires October 11, 2015 [Page 56] Internet-Draft EMAN Framework January 2014 Diegem 1813 BE Phone: +32 2 704 5622 Email: bclaise@cisco.com Brad Schoening 44 Rivers Edge Drive Little Silver, NJ 07739 US Phone: Email: brad.schoening@verizon.net Juergen Quittek NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 90511 15 EMail: quittek@netlab.nec.de Claise et al. Expires October 11, 2015 [Page 57]