Internet DRAFT - draft-ietf-eman-framework
draft-ietf-eman-framework
Network Working Group J. Parello
Internet-Draft B. Claise
Intended Status: Informational Cisco Systems, Inc.
Expires: October 28, 2014 B. Schoening
Independent Consultant
J. Quittek
NEC Europe Ltd
April 28, 2014
Energy Management Framework
draft-ietf-eman-framework-19
Status of this Memo
This Internet-Draft is submitted in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by
other documents at any time. It is inappropriate to use
Internet-Drafts as reference material or to cite them other
than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be
accessed at http://www.ietf.org/shadow.html
This Internet-Draft will expire on October 2 2014.
Claise, et al Expires October 28, 2014 [Page 1]
Internet-Draft EMAN Framework April 2014
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as
the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's
Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the
date of publication of this document. Please review these
documents carefully, as they describe your rights and
restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD
License text as described in Section 4.e of the Trust Legal
Provisions and are provided without warranty as described
in the Simplified BSD License.
Abstract
This document defines a framework for Energy Management for
devices and device components within or connected to
communication networks. The framework presents a physical
reference model and information model. The information
model consists of an Energy Management Domain as a set of
Energy Objects. Each Energy Object can be attributed with
identity, classification, and context. Energy Objects can
be monitored and controlled with respect to power, Power
State, energy, demand, Power Attributes, and battery.
Additionally the framework models relationships and
capabilities between Energy Objects.
Claise, et al. Expires October 28, 2014 [Page 2]
Internet-Draft EMAN Framework April 2014
Table of Contents
1. Introduction .............................................. 3
2. Terminology ............................................... 4
3. Target Devices ............................................ 10
4. Physical Reference Model .................................. 11
5. Not Covered by the Framework .............................. 12
6. Energy Management Abstraction ............................. 13
6.1. Conceptual Model ..................................... 13
6.2. Energy Object (Class) ................................ 14
6.3. Energy Object Attributes ............................. 15
6.4. Measurements ......................................... 18
6.5. Control .............................................. 20
6.6. Relationships ........................................ 26
7. Energy Management Information Model ....................... 30
8. Modeling Relationships between Devices .................... 34
8.1. Power Source Relationship ............................ 34
8.2. Metering Relationship ................................ 38
8.3. Aggregation Relationship ............................. 39
9. Relationship to Other Standards ........................... 40
10. Implementation Status .................................... 40
11. Security Considerations .................................. 41
11.1. Security Considerations for SNMP .................... 41
12. IANA Considerations....................................... 42
12.1. IANA Registration of new Power State Sets ........... 42
12.2. Updating the Registration of Existing Power State
Sets ...................................................... 44
13. References ............................................... 44
14. Acknowledgments .......................................... 47
Appendix A. Information Model Listing ........................ 47
Authors' Addresses ........................................... 56
1. Introduction
Network management is often divided into the five main
areas defined in the ISO Telecommunications Management
Network model: Fault, Configuration, Accounting,
Performance, and Security Management (FCAPS) [X.700]. Not
covered by this traditional management model is Energy
Management, which is rapidly becoming a critical area of
concern worldwide, as seen in [ISO50001].
This document defines an Energy Management framework for
devices within or connected to communication networks, per
the Energy Management requirements specified in [RFC6988].
The devices or components of these devices (such as line
cards, fans, and disks) can then be monitored and
controlled. Monitoring includes measuring power, energy,
demand, and attributes of power. Energy control can be
Claise, et al. Expires October 28, 2014 [Page 3]
Internet-Draft EMAN Framework April 2014
performed by setting a devices' or components' state. The
devices monitored by this framework can be either consumers
of energy (such as routers and computer systems) and
components of such devices (such as line cards, fans, and
disks), or they can be producers of energy (like an
uninterruptible power supply or renewable energy system)
and their associated components (such as battery cells,
inverters, or photovoltaic panels).
This framework further describes how to identify, classify
and provide context for such devices. While context
information is not specific to Energy Management, some
context attributes are specified in the framework,
addressing the following use cases: how important is a
device in terms of its business impact, how should devices
be grouped for reporting and searching, and how should a
device role be described. Guidelines for using context for
Energy Management are described.
The framework introduces the concept of a Power Interface
that is analogous to a network interface. A Power Interface
is defined as an interconnection among devices where energy
can be provided, received, or both.
The most basic example of Energy Management is a single
device reporting information about itself. In many cases,
however, energy is not measured by the device itself, but
measured upstream in the power distribution tree. For
example, a power distribution unit (PDU) may measure the
energy it supplies to attached devices and report this to
an energy management system. Therefore, devices often have
relationships to other devices or components in the power
network. An EnMS (Energy Management System) generally
requires an understanding of the power topology (who
provides power to whom), the metering topology (who meters
whom), and an understanding of the potential aggregation
(who aggregates values of others).
The relationships build on the Power Interface concept. The
different relationships among devices and components,
specified in this document, include: power source,
metering, and aggregation relationships.
The framework does not cover non-electrical equipment nor
does it cover energy procurement and manufacturing.
2. Terminology
Claise, et al. Expires October 28, 2014 [Page 4]
Internet-Draft EMAN Framework April 2014
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in RFC-2119 [RFC2119].
In this document these words will appear with that
interpretation only when in ALL CAPS. Lower case uses of
these words are not to be interpreted as carrying RFC-2119
significance.
In this section some terms have a NOTE that is not part of
the definition itself, but accounts for differences between
terminologies of different standards organizations or
further clarifies the definition.
The terms are listing in an order that aids in reading
where terms may build off a previous term as opposed to an
alphabetical ordering. Some terms that are common in
electrical engineering or that describe common physical
items use a lower case notation.
Energy Management
Energy Management is a set of functions for measuring,
modeling, planning, and optimizing networks to ensure
that the network and network attached devices use energy
efficiently and appropriately for the nature of the
application and the cost constraints of the organization.
Reference: Adapted from [ITU-T-M-3400]
NOTES:
1. Energy Management refers to the activities, methods,
procedures and tools that pertain to measuring, modeling,
planning, controlling and optimizing the use of energy in
networked systems [NMF].
2. Energy Management is a management domain which is
congruent to any of the FCAPS areas of management in the
ISO/OSI Network Management Model [TMN]. Energy Management
for communication networks and attached devices is a
subset or part of an organization's greater Energy
Management Policies.
Energy Management System (EnMS)
An Energy Management System is a combination of hardware
and software used to administer a network with the
primary purpose of energy management.
NOTES:
Claise, et al. Expires October 28, 2014 [Page 5]
Internet-Draft EMAN Framework April 2014
1. An Energy Management System according to [ISO50001]
(ISO-EnMS) is a set of systems or procedures upon which
organizations can develop and implement an energy policy,
set targets, action plans and take into account legal
requirements related to energy use. An ISO-EnMS allows
organizations to improve energy performance and
demonstrate conformity to requirements, standards, and/or
legal requirements.
2. Example ISO-EnMS: Company A defines a set of policies
and procedures indicating there should exist multiple
computerized systems that will poll energy measurements
from their meters and pricing / source data from their
local utility. Company A specifies that their CFO (Chief
Financial Officer) should collect information and
summarize it quarterly to be sent to an accounting firm
to produce carbon accounting reporting as required by
their local government.
3. For the purposes of EMAN, the definition herein is the
preferred meaning of an Energy Management System (EnMS).
The definition from [ISO50001] can be referred to as ISO
Energy Management System (ISO-EnMS).
Energy Monitoring
Energy Monitoring is a part of Energy Management that
deals with collecting or reading information from devices
to aid in Energy Management.
Energy Control
Energy Control is a part of Energy Management that deals
with directing influence over devices.
electrical equipment
A general term including materials, fittings, devices,
appliances, fixtures, apparatus, machines, etc., used as
a part of, or in connection with, an electric
installation.
Reference: [IEEE100]
non-electrical equipment (mechanical equipment)
A general term including materials, fittings, devices,
appliances, fixtures, apparatus, machines, etc., used as
a part of, or in connection with, non-electrical power
installations.
Reference: Adapted from [IEEE100]
device
Claise, et al. Expires October 28, 2014 [Page 6]
Internet-Draft EMAN Framework April 2014
A piece of electrical or non-electrical equipment.
Reference: Adapted from [IEEE100]
component
A part of an electrical or non-electrical equipment
(device).
Reference: Adapted from [ITU-T-M-3400]
power inlet
A power inlet (or simply inlet) is an interface at which
a device or component receives energy from another device
or component.
power outlet
A power outlet (or simply outlet) is an interface at
which a device or component provides energy to another
device or component.
energy
That which does work or is capable of doing work. As used
by electric utilities, it is generally a reference to
electrical energy and is measured in kilowatt hours
(kWh).
Reference: [IEEE100]
NOTES
1. Energy is the capacity of a system to produce external
activity or perform work [ISO50001]
power
The time rate at which energy is emitted, transferred, or
received; usually expressed in watts (joules per second).
Reference: [IEEE100]
demand
The average value of power or a related quantity over a
specified interval of time. Note: Demand is expressed in
kilowatts, kilovolt-amperes, kilovars, or other suitable
units.
Reference: [IEEE100]
NOTES:
1. While IEEE100 defines demand in kilo measurements, for
EMAN we use watts with any suitable metric prefix.
Claise, et al. Expires October 28, 2014 [Page 7]
Internet-Draft EMAN Framework April 2014
provide energy
A device (or component) "provides" energy to another
device if there is an energy flow from this device to the
other one.
receive energy
A device (or component) "receives" energy from another
device if there is an energy flow from the other device
to this one.
meter (energy meter)
a device intended to measure electrical energy by
integrating power with respect to time.
Reference: Adapted from [IEC60050]
battery
one or more cells (consisting of an assembly of
electrodes, electrolyte, container, terminals and usually
separators) that are a source and/or store of electric
energy.
Reference: Adapted from [IEC60050]
Power Interface
A power inlet, outlet, or both.
Nameplate Power
The Nameplate Power is the nominal power of a device as
specified by the device manufacturer.
Power Attributes
Measurements of the electrical current, voltage, phase
and frequencies at a given point in an electrical power
system.
Reference: Adapted from [IEC60050]
NOTES:
1. Power Attributes are not intended to provide any
bounds or recommended range for the value. They are
simply the reading of the value associated with the
attribute in question.
Power Quality
Characteristics of the electrical current, voltage, phase
and frequencies at a given point in an electric power
system, evaluated against a set of reference technical
parameters. These parameters might, in some cases, relate
Claise, et al. Expires October 28, 2014 [Page 8]
Internet-Draft EMAN Framework April 2014
to the compatibility between electricity supplied in an
electric power system and the loads connected to that
electric power system.
Reference: [IEC60050]
NOTES:
1. Electrical characteristics representing power quality
information are typically required by customer facility
energy management systems. It is not intended to satisfy
the detailed requirements of power quality monitoring.
Standards typically also give ranges of allowed values;
the information attributes are the raw measurements, not
the "yes/no" determination by the various standards.
Reference: [ASHRAE-201]
Power State
A Power State is a condition or mode of a device (or
component) that broadly characterizes its capabilities,
power, and responsiveness to input.
Reference: Adapted from [IEEE1621]
Power State Set
A Power State Set is a collection of Power States that
comprises a named or logical control grouping.
Claise, et al. Expires October 28, 2014 [Page 9]
Internet-Draft EMAN Framework April 2014
3. Target Devices
With Energy Management, there exists a wide variety of
devices that may be contained in the same deployment as a
communication network but comprise a separate facility,
home, or power distribution network.
Energy Management has special challenges because a power
distribution network supplies energy to devices and
components, while a separate communications network
monitors and controls the power distribution network.
The target devices for Energy Management are all devices
that can be monitored or controlled (directly or
indirectly) by an Energy Management System (EnMS). These
target devices include, for example:
. Simple electrical appliances and fixtures
. Hosts, such as a PC, a server, or a printer
. Switches, routers, base stations, and other network
equipment and middle boxes
. Components within devices, a line card inside a
switch
. Batteries as a device or component that is a store
of energy
. Devices or components that charge or produce energy
such as solar cells, charging stations or
generators
. Power over Ethernet (PoE) endpoints
. Power Distribution Units (PDU)
. Protocol gateway devices for Building Management
Systems (BMS)
. Electrical meters
. Sensor controllers with subtended sensors
Target devices include devices that communicate via the
Internet Protocol (IP) as well as devices using other means
for communication. The latter are managed through gateways
or proxies that can communicate using IP.
Claise, et al. Expires October 28, 2014 [Page 10]
Internet-Draft EMAN Framework April 2014
4. Physical Reference Model
The following reference model describes physical power
topologies that exist in parallel to a communication
topology. While many more topologies can be created with
combination of devices, the following are some basic ones
that show how Energy Management topologies differ from
Network Management topologies.
NOTE: "###" is used to denote a transfer of energy.
- > is used to denote a transfer of information.
Basic Energy Management
+--------------------------+
| Energy Management System |
+--------------------------+
^ ^
monitoring | | control
v v
+---------+
| device |
+---------+
Basic Power Supply
+-----------------------------------------+
| Energy Management System |
+-----------------------------------------+
^ ^ ^ ^
monitoring | | control monitoring | | control
v v v v
+--------------+ +-----------------+
| power source |########| device |
+--------------+ +-----------------+
Single Power Supply with Multiple Devices
+---------------------------------------+
| Energy Management System |
+---------------------------------------+
^ ^ ^ ^
monitoring | | control monitoring | | control
v v v v
+--------+ +------------------+
| power |########| device 1 |
| source | # +------------------+-+
+--------+ #######| device 2 |
# +------------------+-+
Claise, et al. Expires October 28, 2014 [Page 11]
Internet-Draft EMAN Framework April 2014
#######| device 3 |
+------------------+
Multiple Power Supplies with Single Devices
+----------------------------------------------+
| Energy Management System |
+----------------------------------------------+
^ ^ ^ ^ ^ ^
mon. | | ctrl. mon. | | ctrl. mon. | | ctrl.
v v v v v v
+----------+ +----------+ +----------+
| power |######| device |######| power |
| source 1 | | | | source 2 |
+----------+ +----------+ +----------+
5. Not Covered by the Framework
While this framework is intended as a framework for Energy
Management in general, there are some areas that are not
covered.
Non-Electrical Equipment
The primary focus of this framework is the management of
electrical equipment. Non-Electrical equipment, not covered
in this framework, could nevertheless be modeled by
providing interfaces that comply with the framework: for
example, using the same units for power and energy.
Therefore, non-electrical equipment that do not convert-to
or present-as equivalent to electrical equipment are not
addressed.
Energy Procurement and Manufacturing
While an EnMS may be a central point for corporate
reporting, cost computation, environmental impact analysis,
and regulatory compliance reporting - Energy Management in
this framework excludes energy procurement and the
environmental impact of energy use.
As such the framework does not include:
o Cost in currency or environmental units of
manufacturing a device.
o Embedded carbon or environmental equivalences of a
device
Claise, et al. Expires October 28, 2014 [Page 12]
Internet-Draft EMAN Framework April 2014
o Cost in currency or environmental impact to dismantle
or recycle a device.
o Supply chain analysis of energy sources for device
deployment
o Conversion of the usage or production of energy to
units expressed from the source of that energy (such
as the greenhouse gas emissions associated the
transfer of energy from a diesel source).
6. Energy Management Abstraction
This section describes a conceptual model of information
that can be used for Energy Management. The classes and
categories of attributes in the model are described with
rationale for each.
6.1. Conceptual Model
This section describes an information model that addresses
issues specific to Energy Management, which complements
existing Network Management models.
An information model for Energy Management will need to
describe a means to monitor and control devices and
components. The model will also need to describe the
relationships among and connections between devices and
components.
This section defines a similar conceptual model for devices
and components to that used in Network Management: devices,
components, and interfaces. This section then defines the
additional attributes specific to Energy Management for
those entities that are not available in existing Network
Management models.
For modeling the devices and components this section
describes three classes denoted by a "(Class)" suffix: a
Device (Class), a Component (Class), and a Power Interface
(Class). These classes are sub-types of an abstract Energy
Object (Class).
Summary of Notation for Modeling Physical Equipment
Physical Modeling (Meta Data) Model Instance
---------------------------------------------------------
equipment Energy Object (Class) Energy Object
device Device (Class) Device
component Component (Class) Component
inlet / outlet Power Interface (Class) Power Interface
Claise, et al. Expires October 28, 2014 [Page 13]
Internet-Draft EMAN Framework April 2014
This section then describes the attributes of an Energy
Object (Class) for identification, classification, context,
control, power and energy.
Since the interconnections between devices and components
for Energy Management may have no relation to the
interconnections for Network Management the Energy Object
(Classes) contain a separate Relationships (Class) as an
attribute to model these types of interconnections.
The next sections describe the each of the classes and
categories of attributes in the information model.
Not all of the attributes are mandatory for
implementations. Specifications describing implementations
of the information model in this framework need to be
explicit about which are mandatory and which are optional
to implement
The formal definitions of the classes and attributes are
specified in Section 7.
6.2. Energy Object (Class)
An Energy Object (Class) represents a piece of equipment
that is part of, or attached to, a communications network
which is monitored, controlled, or aids in the management
of another device for Energy Management.
The Energy Object (Class) is an abstract class that
contains the base attributes to represent a piece of
equipment for Energy Management. There are three types of
Energy Object (Class): Device (Class), Component (Class)
and Power Interface (Class).
6.2.1. Device (Class)
The Device (Class) is a sub-class of Energy Object (Class)
that represents a physical piece of equipment.
A Device (Class) instance represents a device that is a
consumer, producer, meter, distributor, or store of energy.
A Device (Class) instance may represent a physical device
that contains other components.
Claise, et al. Expires October 28, 2014 [Page 14]
Internet-Draft EMAN Framework April 2014
6.2.2. Component (Class)
The Component (Class) is a sub-class of Energy Object
(Class) that represents a part of a physical piece of
equipment.
6.2.3. Power Interface (Class)
A Power Interface (Class) represents the interconnections
(inlet, outlet) among devices or components where energy
can be provided, received, or both.
The Power Interface (Class) is a sub-class of Energy Object
(Class) that represents a physical inlet or outlet.
There are some similarities between Power Interfaces and
network interfaces. A network interface can be set to
different states, such as sending or receiving data on an
attached line. Similarly, a Power Interface can be
receiving or providing energy.
A Power Interface (Class) instance can represent
(physically) an AC power socket, an AC power cord attached
to a device, or an 8P8C (RJ45) PoE socket, etc.
6.3. Energy Object Attributes
This section describes categories of attributes for an
Energy Object (Class).
6.3.1. Identification
A Universal Unique Identifier (UUID) [RFC4122] is used to
uniquely and persistently identify an Energy Object.
Every Energy Object has an optional unique human readable
printable name. Possible naming conventions are: textual
DNS name, MAC address of the device, interface ifName, or a
text string uniquely identifying the Energy Object. As an
example, in the case of IP phones, the Energy Object name
can be the device's DNS name.
Additionally an alternate key is provided to allow an
Energy Object to be optionally linked with models in
different systems.
6.3.2. Context: General
Claise, et al. Expires October 28, 2014 [Page 15]
Internet-Draft EMAN Framework April 2014
In order to aid in reporting and in differentiation between
Energy Objects, each object optionally contains information
establishing its business, site, or organizational context
within a deployment.
The Energy Object (Class) contains a category attribute
that broadly describes how an instance is used in a
deployment. The category indicates if the Energy Object is
primarily functioning as a consumer, producer, meter,
distributor or store of energy.
Given the category and context of an object, an EnMS can
summarize or analyze measurements for the site.
6.3.3. Context: Importance
An Energy Object can provide an importance value in the
range of 1 to 100 to help rank a device's use or relative
value to the site. The importance range is from 1 (least
important) to 100 (most important). The default importance
value is 1.
For example: A typical office environment has several types
of phones, which can be rated according to their business
impact. A public desk phone has a lower importance (for
example, 10) than a business-critical emergency phone (for
example, 100). As another example: A company can consider
that a PC and a phone for a customer-service engineer are
more important than a PC and a phone for lobby use.
Although EnMS and administrators can establish their own
ranking, the following example is a broad recommendation
for commercial deployments [CISCO-EW]:
90 to 100 Emergency response
80 to 90 Executive or business-critical
70 to 79 General or Average
60 to 69 Staff or support
40 to 59 Public or guest
1 to 39 Decorative or hospitality
6.3.4. Context: Keywords
The Energy Object (Class) contains an attribute with
context keywords.
An Energy Object can provide a set of keywords that are a
list of tags that can be used for grouping, for summary
reporting (within or between Energy Management Domains),
Claise, et al. Expires October 28, 2014 [Page 16]
Internet-Draft EMAN Framework April 2014
and for searching. Potential examples are: IT, lobby,
HumanResources, Accounting, StoreRoom, CustomerSpace,
router, phone, floor2, or SoftwareLab.
The specifics of how this tag is represented are left to
the MIB module or other object definition documents to be
based on this framework.
There is no default value for a keyword. Multiple keywords
can be assigned to an Energy Object.
6.3.5. Context: Role
The Energy Object (Class) contains a role attribute. The
"role description" string indicates the primary purpose the
Energy Object serves in the deployment. This could be a
string representing the purpose the Energy Object fulfills
in the deployment.
The specifics of how this tag is represented are left to
the MIB module or other object definition documents to be
based on this framework.
Administrators can define any naming scheme for the role.
As guidance, a two-word role that combines the service the
Energy Object provides along with type can be used
[IPENERGY].
Example types of devices: Router, Switch, Light, Phone,
WorkStation, Server, Display, Kiosk, HVAC.
Example Services by Line of Business:
Line of Business Service
-----------------------------------------------------
Education Student, Faculty,
Administration,
Athletic
Finance Trader, Teller, Fulfillment
Manufacturing Assembly, Control, Shipping
Retail Advertising, Cashier
Support Helpdesk, Management
Medical Patient, Administration, Billing
Role as a two-word string: "Faculty Desktop", "Teller
Phone", "Shipping HVAC", "Advertising Display", "Helpdesk
Kiosk", "Administration Switch".
Claise, et al. Expires October 28, 2014 [Page 17]
Internet-Draft EMAN Framework April 2014
The specifics of how this tag is represented are left to
the MIB module or other object definition documents to be
based on this framework.
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.
The specifics of how this tag is represented are left to
the MIB module or other object definition documents to be
based on this framework.
An Energy Object MUST 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.
Claise, et al. Expires October 28, 2014 [Page 18]
Internet-Draft EMAN Framework April 2014
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
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 [IEC61850-7-2] standard for
describing AC measurements.
Claise, et al. Expires October 28, 2014 [Page 19]
Internet-Draft EMAN Framework April 2014
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.
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 Printer Working Group (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:
Claise, et al. Expires October 28, 2014 [Page 20]
Internet-Draft EMAN Framework April 2014
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.
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
Claise, et al. Expires October 28, 2014 [Page 21]
Internet-Draft EMAN Framework April 2014
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 (2), sleep (1), and off (0). Any additional
power states are variants of one of the basic states rather
than a fourth state [IEEE1621].
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
Claise, et al. Expires October 28, 2014 [Page 22]
Internet-Draft EMAN Framework April 2014
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]
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(0) to
ready(5)), the Power State preceding it is expected to have
a lower Power value and a longer delay in returning to an
operational state:
mechoff(0) : 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(1) : Similar to mechoff(0), but some
components remain powered or receive trace power so that
the Energy Object can be awakened from its off state. In
softoff(1), no context is saved and the device typically
requires a complete boot when awakened.
hibernate(2): No Energy Object features are
available. The Energy Object may be awakened without
Claise, et al. Expires October 28, 2014 [Page 23]
Internet-Draft EMAN Framework April 2014
requiring a complete boot, but the time for availability is
longer than sleep(3). An example for state hibernate(2) is
a save to-disk state where DRAM context is not maintained.
Typically, energy consumption is zero or close to zero.
sleep(3) : 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(4). An example for state sleep(3) is a save-to-RAM
state, where DRAM context is maintained. Typically, energy
consumption is close to zero.
standby(4) : 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(5). For
example processor context is may not be maintained.
Typically, energy consumption is close to zero.
ready(5) : 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(6) : 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(7).
low(7) : Indicates some features may not be
available and the Energy Object has taken measures or
selected options to use less energy than mediumMinus(8).
mediumMinus(8): Indicates all Energy Object
features are available but the Energy Object has taken
measures or selected options to use less energy than
medium(9).
medium(9) : Indicates all Energy Object features
are available but the Energy Object has taken measures or
selected options to use less energy than highMinus(10).
highMinus(10): Indicates all Energy Object
features are available and has taken measures or selected
options to use less energy than high(11).
Claise, et al. Expires October 28, 2014 [Page 24]
Internet-Draft EMAN Framework April 2014
high(11) : 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 28, 2014 [Page 25]
Internet-Draft EMAN Framework April 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(0)
off Off-Soft G2, S5 softoff(1)
off Hibernate G1, S4 hibernate(2)
sleep Sleep-Deep G1, S3 sleep(3)
sleep Sleep-Light G1, S2 standby(4)
sleep Sleep-Light G1, S1 ready(5)
Operational states:
on on G0, S0, P5 lowMinus(6)
on on G0, S0, P4 low(7)
on on G0, S0, P3 mediumMinus(8)
on on G0, S0, P2 medium(9)
on on G0, S0, P1 highMinus(10)
on on G0, S0, P0 high(11)
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.
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.
Claise, et al. Expires October 28, 2014 [Page 26]
Internet-Draft EMAN Framework April 2014
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
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
Claise, et al. Expires October 28, 2014 [Page 27]
Internet-Draft EMAN Framework April 2014
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.
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
Claise, et al. Expires October 28, 2014 [Page 28]
Internet-Draft EMAN Framework April 2014
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
the information model, but the rules and logical ability to
aggregate each attribute is out of scope for this document.
In general:
Claise, et al. Expires October 28, 2014 [Page 29]
Internet-Draft EMAN Framework April 2014
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 MIB
modules 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.
Syntax
UML Construct
[ISO-IEC-19501-2005] Equivalent Notation
-------------------- ------------------------------------
Claise, et al. Expires October 28, 2014 [Page 30]
Internet-Draft EMAN Framework April 2014
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 28, 2014 [Page 31]
Internet-Draft EMAN Framework April 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
stored : long
Claise, et al. Expires October 28, 2014 [Page 32]
Internet-Draft EMAN Framework April 2014
}
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}
avgVoltage : long
Claise, et al. Expires October 28, 2014 [Page 33]
Internet-Draft EMAN Framework April 2014
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
Interfaces to indicate the source of energy for a device.
Claise, et al. Expires October 28, 2014 [Page 34]
Internet-Draft EMAN Framework April 2014
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:
o Device W has an Energy Object representing the
computer.
Claise, et al. Expires October 28, 2014 [Page 35]
Internet-Draft EMAN Framework April 2014
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:
o Device X has an Energy Object representing the
computer. Device Y has an Energy Object representing
the PDU.
Claise, et al. Expires October 28, 2014 [Page 36]
Internet-Draft EMAN Framework April 2014
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 | | |
+-------+------+ +------+----------+
Without Power Interfaces:
Claise, et al. Expires October 28, 2014 [Page 37]
Internet-Draft EMAN Framework April 2014
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:
+---------------+
| Device 1 |
+---------------+
| PI |
Claise, et al. Expires October 28, 2014 [Page 38]
Internet-Draft EMAN Framework April 2014
+---------------+
|
+---------------+
| 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
[RFC7015], 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 28, 2014 [Page 39]
Internet-Draft EMAN Framework April 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
RFC Editor Note: 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 28, 2014 [Page 40]
Internet-Draft EMAN Framework April 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 will have negative effects on network
capabilities. Event logs for audit purposes on
configuration and other changes should be generated
according to current authorization, audit, and accounting
principles to facilitate investigations (compromise or
benign mis-configurations) or any reporting requirements.
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.
Claise, et al. Expires October 28, 2014 [Page 41]
Internet-Draft EMAN Framework April 2014
For example:
o Unauthorized changes to the Energy Management Domain
or business context of a device will result in
misreporting or interruption of power.
o Unauthorized changes to a power state will 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 will
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
confidentiality).
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
Claise, et al. Expires October 28, 2014 [Page 42]
Internet-Draft EMAN Framework April 2014
specific implementation of Power State Set shall not be
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.5.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.5.3. 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.5.4. IANA has created a new registry
for EMAN Power State Set identifiers and filled it with the
initial list of identifiers.
Claise, et al. Expires October 28, 2014 [Page 43]
Internet-Draft EMAN Framework April 2014
New assignments (or potentially deprecation) for the EMAN
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.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
[RFC3444] Pras, A., Schoenwaelder, J. "On the Differences
between Information Models and Data Models", RFC
3444, January 2003
[RFC4122] Leach, P., Mealling, M., and R. Salz," A
Universally Unique Identifier (UUID) URN
Namespace", RFC 4122, July 2005
Claise, et al. Expires October 28, 2014 [Page 44]
Internet-Draft EMAN Framework April 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
[RFC6988] Quittek, J., Chandramouli, M., Winter, R.,
Dietz, T., and B. Claise, "Requirements for
Energy Management", RFC 6988, Septembre 2013
[ISO-IEC-19501-2005] ISO/IEC 19501:2005, Information
technology, Open Distributed Processing --
Unified Modeling Language (UML), January 2005
Informative References
[RFC3986] T. Berners-Lee, Ed., " Uniform Resource
Identifier (URI): Generic Syntax", RFC3 986,
January 2005
[RFC6982] Y. Sheffer, and Adrian Farrel, "Improving
Awareness of Running Code: The Implementation
Status Section", RFC 6982, July 2013
[RFC7015] B. Trammell, A. Wagner, and B. Claise, "Flow
Aggregation for the IP Flow Information Export
(IPFIX) Protocol", RFC 7015, September 2013
[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
[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
Claise, et al. Expires October 28, 2014 [Page 45]
Internet-Draft EMAN Framework April 2014
[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
[IEC61850] Power Utility Automation,
http://www.iec.ch/smartgrid/standards/
[IEC61850-7-2] Abstract communication service interface
(ACSI), http://www.iec.ch/smartgrid/standards/
[IEC61850-7-4] Compatible logical node classes and data
classes, http://www.iec.ch/smartgrid/standards/
[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 28, 2014 [Page 46]
Internet-Draft EMAN Framework April 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
Claise, et al. Expires October 28, 2014 [Page 47]
Internet-Draft EMAN Framework April 2014
or searching
rw importance Integer Specifies a ranking of
how important the
Energy Object is (on a
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 28, 2014 [Page 48]
Internet-Draft EMAN Framework April 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 28, 2014 [Page 49]
Internet-Draft EMAN Framework April 2014
Nameplate (Class)
r nominalPower PowerMeasuremen The nominal power of
t 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 Enumeratio A description of the
n 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 28, 2014 [Page 50]
Internet-Draft EMAN Framework April 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
previous timestamp
Claise, et al. Expires October 28, 2014 [Page 51]
Internet-Draft EMAN Framework April 2014
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 28, 2014 [Page 52]
Internet-Draft EMAN Framework April 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
Claise, et al. Expires October 28, 2014 [Page 53]
Internet-Draft EMAN Framework April 2014
since last reset
r entryCount Long Indicates the number of
time the Energy Object
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
Claise, et al. Expires October 28, 2014 [Page 54]
Internet-Draft EMAN Framework April 2014
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-
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
[IEC61850-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
Claise, et al. Expires October 28, 2014 [Page 55]
Internet-Draft EMAN Framework April 2014
[IEC61850-7-4] 'PF'
DelPhase (Class) inherits from and specializes ACPhase
r phaseToNextPhas Long A measured value of phase to
eVoltage next 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
[IEC61850-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
Claise, et al. Expires October 28, 2014 [Page 56]
Internet-Draft EMAN Framework April 2014
US
Phone: +1 408 525 2339
Email: jparello@cisco.com
Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
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 28, 2014 [Page 57]
