wdiff rfc7326.alt-original rfc7326.txt

Network Working Group
Internet Engineering Task Force (IETF) J. Parello
Internet-Draft
Request for Comments: 7326 B. Claise
Intended Status:
Category: Informational Cisco Systems, Inc.
Expires: October 28, 2014
ISSN: 2070-1721 B. Schoening
Independent Consultant
J. Quittek
NEC Europe Ltd

April 28, Ltd.
September 2014

Energy Management Framework
draft-ietf-eman-framework-19

Abstract

This document defines a framework for Energy Management (EMAN) for
devices and device components within within, or connected to 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 Additionally,
the framework models relationships and capabilities between Energy
Objects.

Status of this This Memo

This Internet-Draft document is submitted in full conformance with
the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents not an Internet Standards Track specification; it is
published for informational purposes.

This document is a product 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
(IETF). It represents the consensus of
six months the IETF community. It has
received public review and may be updated, replaced, or obsoleted has been approved for publication by
other the
Internet Engineering Steering Group (IESG). Not all documents at
approved by the IESG are a candidate for any time. It is inappropriate to use
Internet-Drafts as reference material or to cite them other
than as "work in progress."

The list level of Internet
Standard; see Section 2 of RFC 5741.

Information about the current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list status of Internet-Draft Shadow Directories can this document, any errata,
and how to provide feedback on it may be
accessed obtained at http://www.ietf.org/shadow.html

This Internet-Draft will expire on October 2 2014.
http://www.rfc-editor.org/info/rfc7326.

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.

Table of Contents

1. Introduction .............................................. 3 ....................................................3
2. Terminology ............................................... 4 .....................................................4
3. Target Devices ............................................ 10 ..................................................9
4. Physical Reference Model .................................. 11 .......................................10
5. Areas Not Covered by the Framework .............................. 12 .............................11
6. Energy Management Abstraction ............................. 13 ..................................12
6.1. Conceptual Model ..................................... 13 ..........................................12
6.2. Energy Object (Class) ................................ 14 .....................................13
6.3. Energy Object Attributes ............................. 15 ..................................15
6.4. Measurements ......................................... 18 ..............................................18
6.5. Control .............................................. 20 ...................................................19
6.6. Relationships ........................................ 26 .............................................25
7. Energy Management Information Model ....................... 30 ............................29
8. Modeling Relationships between Devices .................... 34 .........................33
8.1. Power Source Relationship ............................ 34 .................................33
8.2. Metering Relationship ................................ 38 .....................................37
8.3. Aggregation Relationship ............................. 39 ..................................38
9. Relationship to Other Standards ........................... 40 ................................39
10. Implementation Status .................................... 40
11. Security Considerations .................................. 41
11.1. .......................................39
10.1. Security Considerations for SNMP .................... 41
12. .........................40
11. IANA Considerations....................................... 42
12.1. Considerations ...........................................41
11.1. IANA Registration of new New Power State Sets ........... 42
12.2. ................41
11.2. Updating the Registration of Existing Power State Sets ...................................................... 44
13. ...42
12. References ............................................... 44
14. ....................................................43
12.1. Normative References .....................................43
12.2. Informative References ...................................44
13. Acknowledgments .......................................... 47 ...............................................45
Appendix A. Information Model Listing ........................ 47
Authors' Addresses ........................................... 56 .............................46

1. Introduction

Network management 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 devices, or the
components of these devices (such as line cards, fans, and disks) disks),
can then be monitored and controlled. Monitoring includes measuring
power, energy, demand, and attributes of power. Energy control Control can
be performed by setting a devices' device's or components' component's state. The devices
monitored by this framework can be either of the following:

o 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 disks)

o producers of energy (like an uninterruptible power supply or
renewable energy system) and their associated components (such as
battery cells, inverters, or photovoltaic panels). panels)

This framework further describes how to identify, classify 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

o How important is a device in terms of its business impact, how impact?

o How should devices be grouped for reporting and searching, and how searching?

o How should a device role be described. 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, itself but is measured upstream in the
power distribution tree. For example, a power distribution unit Power Distribution Unit
(PDU) may measure the energy it supplies to attached devices and
report this to an energy management system. Energy Management System. Therefore, devices often
have relationships to other devices or components in the power
network. An EnMS (Energy Energy Management System) System (EnMS) generally requires an
understanding of the power topology (who provides power to whom), the metering
Metering topology (who meters whom), and an understanding of the potential aggregation Aggregation
(who aggregates values of others).

The relationships build on the Power Interface concept. The
different relationships among devices and components, as specified in
this document, include: include power source,
metering, Metering, and aggregation relationships. Aggregation
Relationships.

The framework does not cover non-electrical equipment equipment, nor does it
cover energy procurement and manufacturing.

2. Terminology

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 RFC 2119 [RFC2119].

In this document document, these words will appear with that the above
interpretation only when in ALL CAPS. Lower case Lowercase uses of these words
are not to be interpreted as carrying RFC-2119
significance. the significance of RFC 2119
key words.

In this section section, some terms have a NOTE that is not part of the
definition itself, itself but accounts for differences between terminologies
of different standards organizations or further clarifies the
definition.

The terms are listing listed in an order that aids in reading where terms may
build off a previous term 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 lowercase 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
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] [TMN].

NOTES:

1. Energy Management "Energy Management" refers to the activities, methods,
procedures
procedures, and tools that pertain to measuring, modeling,
planning, controlling controlling, and optimizing the use of energy in
networked systems [NMF].

2. Energy Management is a management domain which that 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 network, with the primary purpose of energy management.
Energy Management.

NOTES:

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, targets and action plans
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 that 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). EnMS. The definition from [ISO50001]
can be referred to as an 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
This is a general term including that includes materials, fittings, devices,
appliances, fixtures, apparatus, machines, etc., that are used as
a part of, or in connection with, an electric installation.

Reference: [IEEE100] [IEEE100].

non-electrical equipment (mechanical equipment)
A
This is a general term including that includes materials, fittings, devices,
appliances, fixtures, apparatus, machines, etc., that are used as
a part of, or in connection with, non-electrical power
installations.

Reference: Adapted from [IEEE100] [IEEE100].

device
A device is a piece of electrical or non-electrical equipment.

Reference: Adapted from [IEEE100] [IEEE100].

component
A component is a part of an electrical or non-electrical equipment
(device).

Reference: Adapted from [ITU-T-M-3400] [TMN].

power inlet
A power inlet (or simply inlet) "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) "outlet") is an interface at which a
device or component provides energy to another device or
component.

energy
That
Energy is 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 kilowatt-hours (kWh).

Reference: [IEEE100]

NOTES [IEEE100].

NOTE:

1. Energy is the capacity of a system to produce external activity
or perform work [ISO50001] [ISO50001].

power
The
Power is the time rate at which energy is emitted, transferred, or
received; power is usually expressed in watts (joules per second).

Reference: [IEEE100] [IEEE100].

demand
The
Demand is 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: [IEEE100].

NOTE:

1. While IEEE100 defines demand in kilo measurements, for EMAN we
use watts with any suitable metric prefix.

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 meter is a device intended to measure electrical energy by
integrating power with respect to time.

Reference: Adapted from [IEC60050] [IEC60050].

battery
A battery is one or more cells (consisting of an assembly of
electrodes, electrolyte, container, terminals terminals, and usually (usually)
separators) that are a source and/or store of electric energy.

Reference: Adapted from [IEC60050] [IEC60050].

Power Interface
A Power Interface is 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
Power Attributes are measurements of the electrical current,
voltage, phase phase, and frequencies at a given point in an electrical
power system.

Reference: Adapted from [IEC60050]

NOTES: [IEC60050].

NOTE:

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
"Power Quality" refers to characteristics of the electrical
current, voltage, phase 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 to the compatibility between electricity supplied in an
electric power system and the loads connected to that electric
power system.

Reference: [IEC60050]

NOTES: [IEC60050].

NOTE:

1. Electrical characteristics representing power quality Power Quality
information are typically required by customer facility
energy management systems. It is Energy
Management Systems. Electrical characteristics are not
intended to satisfy the detailed requirements of power quality 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] [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] [IEEE1621].

Power State Set
A Power State Set is a collection of Power States that comprises a
named or logical control grouping.

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:
.

o Simple electrical appliances and fixtures
.

o Hosts, such as a PC, a server, or a printer
.

o Switches, routers, base stations, and other network equipment and middle boxes
. such
as middleboxes

o Components within devices, e.g., a line card inside a switch
.

o Batteries functioning as a device or component that is a store of
energy
.

o Devices or components that charge or produce energy energy, such as solar
cells, charging stations stations, or generators
.

o Power over Ethernet (PoE) endpoints
.

o Power Distribution Units (PDU)
. (PDUs)

o Protocol gateway devices for Building Management Systems (BMS)
.
o Electrical meters
.

o 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.

4. Physical Reference Model

The following reference model describes physical power topologies
that exist in parallel to with a communication topology. While many
more topologies can be created with a 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 Management:

Basic Power Supply Supply:

Multiple Power Supplies with Single Devices Device:

5. Areas 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 Non-electrical equipment, which is 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 does not convert-to "convert to" or present-as
"present as" an entity equivalent to electrical equipment are is 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 - reporting, Energy Management in this framework excludes
energy procurement and the environmental impact of energy use.

As such such, the framework does not include:

o Cost in currency or environmental units of manufacturing a device.
device

o Embedded carbon or environmental equivalences of a device

o Cost in currency or environmental impact to dismantle or
recycle a device. 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 with the transfer of energy
from a diesel source). 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 described, with a rationale for each.

6.1. Conceptual Model

This section describes an information model that addresses issues
specific to Energy Management, which Management and 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 among, and connections between
between, devices and components.

This section defines a similar conceptual model for devices and components to
that is similar to the model 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 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) (Metadata) Model Instance
---------------------------------------------------------
equipment Energy Object (Class) Energy Object

device Device (Class) Device

component Component (Class) Component
inlet / outlet

inlet/outlet Power Interface (Class) Power Interface

This section then describes the attributes of an Energy Object
(Class) for identification, classification, context, control, power power,
and energy.

Since the interconnections between devices and components for Energy
Management may have no relation to the interconnections for Network Management
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 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 that is monitored, controlled, monitored
or controlled or that 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) (Class), and Power Interface (Class).

6.2.1. Device (Class)

The Device (Class) is a sub-class subclass 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.

6.2.2. Component (Class)

The Component (Class) is a sub-class subclass 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 subclass 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 Universally Unique Identifier (UUID) [RFC4122] is used to uniquely
and persistently identify an Energy Object.

Every Energy Object has an optional unique human readable human-readable printable
name. Possible naming conventions are: are textual DNS name, MAC Media Access
Control (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

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

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 whether the Energy Object is primarily functioning as a
consumer, producer, meter,
distributor 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 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
example, a company can consider that a PC and a phone for a customer-service 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 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 is a list of tags
that can be used for grouping, for summary reporting (within or between
Energy Management Domains), and for searching. Potential examples are: 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
provides, along with type 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".

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 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
Domain; therefore, one attribute is provided.

6.4. Measurements

The Energy Object (Class) contains attributes to describe power, energy
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 traveled; similarly, an
energy measurement indicates the accumulated energy transferred.

Demand measurements are averages of power measurements over time. So
So, using the same analogy to an automobile: measuring the average
vehicle speed over multiple intervals of time for a given distance travelled,
traveled, 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 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 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 magnitude, and
direction of power flow, 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, MW, depending on
the value of the scaling factor. 17 W implies that the BaseValue is = 17
and Scale = 0, whereas 17 mW implies that 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 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.

6.4.3. Measurements: Energy

The Energy Object (Class) contains optional attributes that represent
the energy used, received, produced and or produced, and/or stored. Typically 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 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 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, 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 Distributed Management Task Force (DMTF) standards
organization [DMTF],
ACPI Advanced Configuration and Power Interface
(ACPI) specification [ACPI], and Printer Working Group (PWG) all
define larger numbers of Power States.

The semantics of a Power State are specified by by:

a) the The functionality provided by an Energy Object in this state, state.

b) a A limitation of the power that an Energy Object uses in this state,
state.

c) a A combination of a) and b) 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 An absolute power value value.

o a A percentage value of power relative to the energy
object's nameplate power Energy Object's
Nameplate Power.

o an An indication of power relative to another power
state. Power State. For example: Specify
example, specify that power in state A is less than in state B.

o For supporting Power State management management, an Energy Object provides
statistics on Power States 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. Power State.

When requesting an Energy Object to enter a Power State State, an
indication of the Power State's name or number can be used.
Optionally
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 supports modeling one or multiple Power
State Set implementation(s) implementations on the device or component concurrently.

There are currently three Power State Sets advocated:
IEEE1621(256) specified by IANA:

IEEE1621 (256) - [IEEE1621]
DMTF(512)
DMTF (512) - [DMTF]
EMAN(768)
EMAN (768) - [this document] [RFC7326]

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. section.

6.5.2. Power State Set: IEEE1621

The IEEE1621 Power State Set [IEEE1621] consists of 3 three rudimentary
states: on, off off, or sleep.

In IEEE1621 IEEE1621, devices are limited to the three basic power
states - Power States --
on (2), sleep (1), and off (0). Any additional
power states Power States are
variants of one of the basic states 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 Model), which 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)} Power States.

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. Power States. The following
table provides a mapping between DMTF and ACPI Power State Set: Sets:

DMTF ACPI
------------------------------------------------
Reserved (0)
Reserved (1)
ON (2) G0-S0 G0/S0
Sleep-Light (3) G1-S1 G1-S2 G1/S1 G1/S2
Sleep-Deep (4) G1-S3 G1/S3
Power Cycle (Off-Soft) (5) G2-S5
Off-hard G2/S5
Off-Hard (6) G3
Hibernate (Off-Soft) (7) G1-S4 G1/S4
Off-Soft (8) G2-S5 G2/S5
Power Cycle (Off-Hard) (9) G3
Master Bus Reset (10) G2-S5 G2/S5
Diagnostic Interrupt (11) G2-S5 G2/S5
Off-Soft Graceful (12) G2-S5 G2/S5
Off-Hard Graceful (13) G3
MasterBus Reset Graceful (14) G2-S5 G2/S5
Power Cycle off-soft Off-Soft Graceful (15) G2-S5 G2/S5
Power Cycle off-hard 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 plus the addition of 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 0, and the highest is 6. 5. 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, 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) :

mechoff(0): An off state where no Energy Object features are
available. The Energy Object is unavailable. No energy is
being consumed consumed, and the power connector can be removed.

softoff(1) :

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
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 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 save-to-disk state where DRAM
context is not maintained. Typically, energy consumption is
zero or close to zero.

sleep(3) :

sleep(3): No Energy Object features are available, except for
out-of-band management, such as wake-
up 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) :

standby(4): No Energy Object features are available, except for
out-of-band management, such as wake-
up wake-up mechanisms. This mode
is analogous to cold-standby. The time for availability is
longer than ready(5). For
example example, processor context is may not
be maintained. Typically, energy consumption is close to zero.

ready(5) :

ready(5): No Energy Object features are available, except for
out-of-band management, such as wake-
up 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) :

lowMinus(6): Indicates that 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) :

low(7): Indicates that some Energy Object 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 that 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) :

medium(9): Indicates that 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 that all Energy Object features are
available and the Energy Object has taken measures or selected
options to use less energy than high(11).

high(11) :

high(11): Indicates that all Energy Object features are available
and the Energy Object may use the maximum energy as indicated
by the Nameplate Power.

6.5.5. Power State Sets Comparison

A comparison of Power States from different Power State Sets can be
seen in the following table: tables:

Non-operational states:

IEEE1621 DMTF ACPI EMAN

Non-operational states
--------------------------------------------------
off Off-Hard G3, S5 G3/S5 mechoff(0)
off Off-Soft G2, S5 G2/S5 softoff(1)
off Hibernate G1, S4 G1/S4 hibernate(2)
sleep Sleep-Deep G1, S3 G1/S3 sleep(3)
sleep Sleep-Light G1, S2 G1/S2 standby(4)
sleep Sleep-Light G1, S1 G1/S1 ready(5)
Operational states:

IEEE1621 DMTF ACPI EMAN
----------------------------------------------------
on on G0, S0, P5 G0/S0/P5 lowMinus(6)
on on G0, S0, P4 G0/S0/P4 low(7)
on on G0, S0, P3 G0/S0/P3 mediumMinus(8)
on on G0, S0, P2 G0/S0/P2 medium(9)
on on G0, S0, P1 G0/S0/P1 highMinus(10)
on on G0, S0, P0 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: are Power Source, Metering, and Aggregations.

o A Power Source Relationship is a 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: 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 that the change of power
direction was unintended or an error condition.

o A Metering Relationship is a relationship where one Energy Object
measures power, energy, demand demand, or Power Attributes of one or more
other Energy Objects. The Metering Relationship gives the view of
the metering 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 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) etc.) values for
other devices. The Aggregation Relationship is slightly different
compared to the other
relationships relationships, as this refers more to a
management function.

In some situations, it is not possible to discover the Energy Object relationships,
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 can be excluded with too
strict by making stricter specifications of for
relationships. However, the framework proposes a series of
guidelines, indicated with "SHOULD" and "MAY".

6.6.2. Guidelines: Power Source

Power Source relationships 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 In some cases cases, Energy Objects may not
have the capability to model Power Interfaces. Therefore Therefore, a Power
Source Relationship can be established between two Energy Objects or
two non-connected Power Interfaces.

While strictly speaking Components

Strictly speaking, while components and Power Interfaces on the same
Device do provide or receive energy from each other, the Power Source relationship
Relationship is intended to show energy transfer between Devices. Therefore
Therefore, the relationship is implied when on the same Device.

An Energy Object SHOULD NOT establish a Power Source Relationship
with a Component. 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 cases, the domain
of devices under management may include some devices that do not
implement the framework. In these cases, the Power Source
relationship
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 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, devices may include measuring hardware that can measure power for
components, and outlets 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. 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
system.

In general:

o A Metering Relationship MAY be established with any other Energy
Object, Component, 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 Relationship with one or more of
the meters.

6.6.4. Guidelines: Aggregation

Aggregation relationships Relationships are intended to identify when one device is
used to accumulate values from other devices.
Typically Typically, this is for
energy or power values among devices and not for Components components or Power
Interfaces on the same device.

The intent of Aggregation relationships 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 Aggregation Relationships within the same device would
make modeling more complex complex, and the aggregated values can be implied
from the use of Power Inlets, outlet power inlets, outlet, and Energy Object values on the
same device.

Since an EnMS is naturally a point of aggregation Aggregation, it is not
necessary to model aggregation Aggregation for Energy Management Systems.

The Aggregation Relationship is intended for power and energy. It
MAY be used for aggregation Aggregation of other values from the information
model, but the rules and logical ability to aggregate each attribute is
are out of scope for this document.

In general:

o A Device SHOULD NOT establish an Aggregation Relationship with Components
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. Aggregation.

6.6.5. Energy Object Relationship Extensions

This framework for Energy Management is based on three relationship
types: Aggregation , 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 connected could 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, 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 may, where needed
needed, specify which attributes are required or optional.

Syntax

UML

Unified Modeling
Language (UML)
Construct
[ISO-IEC-19501-2005] Equivalent Notation
-------------------- ------------------------------------ ----------------------------------
Notes // Notes

Class
(Generalization) CLASS name {member..}
Sub-Class
Subclass
(Specialization) CLASS subclass
EXTENDS superclass {member..}
Class Member
(Attribute) attribute : type
Model

CLASS EnergyObject {

// identification / classification
index : int
name : string
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 EnergyMeasurement
demand : DemandMeasurement

// control
powerControl [0..n] : PowerStateSet
}

CLASS PowerInterface EXTENDS EnergyObject{ EnergyObject {
eoIfType : enum { inlet, outlet, both} both }
}

CLASS Device EXTENDS EnergyObject {
eocategory : enum { producer, consumer, meter,
distributor, store }
powerInterfaces[0..n]:
powerInterfaces [0..n] : PowerInterface
components [0..n] : Component
}

CLASS Component EXTENDS EnergyObject {
eocategory : enum { producer, consumer, meter,
distributor, store }
powerInterfaces[0..n]:
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:
multiplier : enum { -24..24} -24..24 }
caliber : enum { actual, estimated, static }
accuracy : enum { 0..10000} 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

}

CLASS TimedMeasurement EXTENDS Measurement {
startTime : timestamp
value : Measurement
maximum : Measurement
}

CLASS TimeInterval {
value : long
units : enum { seconds, miliseconds,...} milliseconds,... }
}
CLASS DemandMeasurement EXTENDS Measurement {
intervalLength : TimeInterval
intervals : long
intervalMode : enum { periodic, sliding, total }
intervalWindow : TimeInterval
sampleRate : TimeInterval
status : enum { active, inactive }
measurements[0..n]
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} { SNGL, DEL, WYE }
avgVoltage : long
avgCurrent : long
thdCurrent : 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 ACQuality {
phaseToNextPhaseVoltage : long
thdVoltage : long
thdCurrent : long
}

CLASS WYEPhase EXTENDS ACPhase ACQuality {
phaseToNeutralVoltage : long
thdCurrent : long
thdVoltage : long
avgCurrent : long
}

8. Modeling Relationships between Devices

In this section 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
controlled 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 Relationship is used to model the interconnections
between devices, components and/Power components, and/or Power Interfaces to indicate the
source of energy for a device.

In the following examples 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
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 inlet, and Power Interface Interfaces 1..10 are outlets.

Device Z: A PDU with multiple Power Interfaces numbered 0..10. Power
Interface 0 is an inlet inlet, and Power Interface Interfaces 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.

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.

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 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.

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:

o Device X has an Energy Object representing the computer. Device
Devices 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 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 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 Metering topology can be used to relate the upstream
meter to the downstream devices in the absence of specific Power
Source relationships. Relationships.

A Metering Relationship can occur between devices that are not
directly connected, as shown in the following figure:

+---------------+
| 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 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 Aggregation is independent of the physical power or
communication topology.

The functions that the aggregation Aggregation point may perform include the
calculation of values such as average, count, maximum, median,
minimum, or the listing (collection) of the aggregation Aggregation values, etc.

Based on the IETF experience gained on aggregations at the IETF Aggregations [RFC7015], the aggregation
Aggregation function in the EMAN framework is limited to the
summation.

When aggregation 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 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).

The specifications of aggregation Aggregation functions are out of the scope of
the EMAN framework, 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
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 characteristics are 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 and 60044-1 class classes 0.1, 0.2, 0.5, 1 1, and 3.
o

- ANSI C12.20 class 0.2, 0.5 classes 0.2 and 0.5.

o The electrical characteristics and quality adhere closely to the
[IEC61850-7-4] standard for describing AC measurements.

o The power state 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 Security Considerations

Regarding the
reference 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 [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, current
authorization, audit, and is based on a proposal
described in [RFC6982]. accounting principles to facilitate
investigations (compromise or benign misconfigurations) or any
reporting requirements.

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
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 information and control capabilities specified in this framework
could be exploited with detriment exploited, to the detriment of a site or deployment.
Implementers of the framework SHOULD examine and mitigate security
threats with respect to these new capabilities.

[RFC3410] User

"User-based Security Model (USM) for SNMPv3 version 3 of the Simple Network
Management Protocol (SNMPv3)" [RFC3414] 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.

10.1. Security Considerations for SNMP

Readable objects in MIB modules (i.e., objects with a MAX-
ACCESS 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:

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 Power State will disrupt the power
settings of the different devices, 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), [RFC3411]), 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.

11. IANA Considerations
12.1.

11.1. IANA Registration of new 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 in
Section 6. IANA maintains the lists of Power State Sets.

New assignments for a 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 vendor-specific implementation of a Power State
Set shall not be
adopted; adopted, since it would lead to proliferation of
Power State Sets.

Power states States in a Power State Set are limited to 255 distinct values. New
A new Power State Set must be assigned the next available numeric
identifier that is a multiple of 256.

12.1.1.

11.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 (or, potentially, deprecation) for the IEEE1621 Power
State Set is 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.

12.1.2. [RFC5226].

11.1.2. IANA Registration of the DMTF Power State Set

This document specifies a set of values for the DMTF Power State Set. Set
[DMTF]. 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 (or, potentially, deprecation) for the DMTF Power
State Set is are administered by IANA through Expert Review [RFC5226], i.e., review by one of a group of experts
designated by an IETF Area Director. [RFC5226].

The group of experts must check the for conformance with the DMTF standard [DMTF],
on the top of
standard [DMTF] in addition to checking for completeness and accuracy
of the description.

12.1.3.

11.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.

New assignments (or potentially (or, potentially, deprecation) for the EMAN Power
State Set is 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.

12.2. [RFC5226].

11.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 post an
individual submission Internet-Draft 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 regarding the deprecation of a
registration.

13.

12. References

12.1. 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, 1997.

[RFC3411] Harrington, D., Presuhn, R., and B.
Stewart, "Introduction Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.

[RFC3414] Blumenthal, U. and Applicability
Statements B. Wijnen, "User-based Security Model
(USM) for Internet Standard version 3 of the Simple Network Management
Framework ",
Protocol (SNMPv3)", STD 62, RFC 3410, 3414, December 2002 2002.

[RFC3444] Pras, A., Schoenwaelder, A. and J. Schoenwaelder, "On the Differences Difference between
Information Models and Data Models", RFC 3444,
January 2003 2003.

[RFC4122] Leach, P., Mealling, M., and R. Salz," A Salz, "A Universally
Unique Identifier IDentifier (UUID) URN Namespace", RFC 4122,
July 2005 2005.

[RFC5226] Narten, T., T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008 2008.

[RFC6933] Bierman, A. A., Romascanu, D., Quittek, J., and K. McCloghrie, M.
Chandramouli, "Entity MIB
(Version4)", (Version 4)", RFC 6933,
May 2013 2013.

[RFC6988] Quittek, J., Ed., Chandramouli, M., Winter, R., Dietz, T.,
and B. Claise, "Requirements for Energy Management",
RFC 6988, Septembre 2013 September 2013.

[ISO-IEC-19501-2005]
ISO/IEC 19501:2005, Information technology, Open
Distributed Processing -- Unified Modeling Language (UML), (UML)
Version 1.4.2, January 2005 2005.

12.2. Informative References

[RFC3986] T. Berners-Lee, Ed., " Uniform T., Fielding, R., and L. Masinter, "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", STD 66,
RFC 6982, July 2013 3986, January 2005.

[RFC7015] B. Trammell, A. B., Wagner, A., and B. Claise, "Flow Aggregation
for the IP Flow Information Export (IPFIX) Protocol",
RFC 7015, September 2013 2013.

[ACPI] "Advanced Configuration and Power Interface
Specification", http://www.acpi.info/spec30b.htm October 2006,
<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 2004.

[NMF] Clemm, A., "Network Management Fundamentals", Alexander Clemm,
ISBN:
ISBN-10: 1-58720-137-2, 2007 Cisco Press, November 2006.

[TMN] International Telecommunication Union, "TMN Management Functions : Performance Management", management
functions", ITU-T M.3400 Recommendation M.3400, February 2000.

[IEEE100] "The Authoritative Dictionary of IEEE Standards
Terms"
http://ieeexplore.ieee.org/xpl/mostRecentIssue.js
p?punumber=4116785 Terms",
<http://ieeexplore.ieee.org/xpl/
mostRecentIssue.jsp?punumber=4116785>.

[ISO50001] "ISO 50001:2011 Energy management systems - -- Requirements
with guidance for use",
http://www.iso.org/ June 2011, <http://www.iso.org/>.

[IEC60050] International "International Electrotechnical Vocabulary
http://www.electropedia.org/iev/iev.nsf/welcome?o
penform Vocabulary",
<http://www.electropedia.org/iev/iev.nsf/
welcome?openform>.

[IEC61850] Power "Power Utility Automation,
http://www.iec.ch/smartgrid/standards/ Automation",
<http://www.iec.ch/smartgrid/standards/>.

[IEC61850-7-2] Abstract
"Abstract communication service interface
(ACSI), http://www.iec.ch/smartgrid/standards/ (ACSI)",
<http://www.iec.ch/smartgrid/standards/>.

[IEC61850-7-4] Compatible
"Compatible logical node classes and data
classes, http://www.iec.ch/smartgrid/standards/ classes",
<http://www.iec.ch/smartgrid/standards/>.

[DMTF] "Power State Management Profile Profile", DMTF DSP1027
Version 2.0" 2.0.0, December 2009
http://www.dmtf.org/sites/default/files/standards
/documents/DSP1027_2.0.0.pdf 2009,
<http://www.dmtf.org/sites/default/files/standards/
documents/DSP1027_2.0.0.pdf>.

[IPENERGY] R. Aldrich, R. and J. Parello Parello, "IP-Enabled Energy
Management", Management:
A Proven Strategy for Administering Energy as a Service",
2010, Wiley Publishing Publishing.

[X.700] CCITT Recommendation X.700 (1992), Management X.700, "Management framework for Open
Systems Interconnection (OSI) for CCITT applications applications",
September 1992.

[ASHRAE-201]
"ASHRAE Standard Project Committee 201 (SPC 201)Facility 201) Facility
Smart Grid Information Model", http://spc201.ashraepcs.org
<http://spc201.ashraepcs.org>.

[CHEN] Chen, P., "The Entity-Relationship Model: Toward a Unified
View of Data", Peter Pin-shan Chen, ACM Transactions on Database Systems, 1976 Systems
(TODS), March 1976.

[CISCO-EW] Parello, J., Saville, R., and S. Kramling, "Cisco
EnergyWise Design Guide", John Parello,
Roland Saville, Steve Kramling, Cisco Validated
Designs, Design (CVD),
September 2010,
http://www.cisco.com/en/US/docs/solutions/Enterpr
ise/Borderless_Networks/Energy_Management/energyw
isedg.html
14. 2011,
<http://www.cisco.com/en/US/docs/solutions/
Enterprise/Borderless_Networks/Energy_Management/
energywisedg.html>.

13. Acknowledgments

The authors would like to thank Michael Brown for his editorial work improving work,
which improved the text dramatically. Thanks to Rolf Winter for his feedback
feedback, and to Bill Mielke for his feedback and very detailed
review. Thanks to Bruce Nordman for brainstorming 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

A. EnergyObject (Class) (Class):

r index Integer An RFC6933 [RFC6933] entPhysicalIndex

w name String An RFC6933 [RFC6933] entPhysicalName

r identifier uuid An [RFC6933] entPhysicalUUID

rw alternatekey String A manufacturer defined manufacturer-defined string
that can be used to identify the
Energy Object

rw domainName String The name of an Energy Management domain
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 scale of 1 to 100) compared
with other Energy Objects

rw relationships Relationship A list of
[0..n] relationships between
[0..n] 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 EnergyMeasurement 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
[0..n] Energy Object supports

B. PowerInterface (Class) inherits from and specializes
EnergyObject EnergyObject:

r eoIfType Enumeration Indicates if whether the Power
Interface is an -
inlet; outlet; inlet, outlet,
or both

C. Device (Class) inherits from and specializes EnergyObject EnergyObject:

rw eocategory Enumeration Broadly indicates if whether
the Device is a
producer consumer meter
distributor producer,
consumer, meter, distributor,
or store of energy

r powerInterfaces PowerInterface A list of
[0..n] PowerInterfaces
[0..n] contained in this Device

r components Component A list of Components components
[0..n] contained in this Device

D. Component (Class) inherits from and specializes
EnergyObject EnergyObject:

rw eocategory Enumeration Broadly indicates if whether the Component
component is a
producer consumer meter
distributor producer,
consumer, meter, distributor, or
store of energy

r powerInterfaces PowerInterface A list of
[0..n] PowerInterfaces
[0..n] contained in this
Component component

r components Component A list of Components
[0..n] components contained
[0..n] in this
Component component
E. Nameplate (Class) (Class):

r nominalPower PowerMeasuremen PowerMeasurement The nominal power of
t the Energy Object
as specified by the device
manufacturer

rw details URI an An [RFC3986] URI that links to
manufacturer information about
the nominal power of a device

F. Relationship (Class) (Class):

rw relationshipType Enumeratio Enumeration A description of the
n relationhip
relationship, indicating
- meters; meteredby;
powers; poweredby;
aggregates;
meters, meteredby, powers,
poweredby, aggregates, or
aggregatedby

rw relationshipObject uuid An [RFC6933] entPhysicalUUID
that indicates the other
participating Energy Object in
the relationship

G. Measurement (Class) (Class):

r multiplier Enumeration The magnitude of the Measurement
in the range -
24..24 -24..24

r caliber Enumeration Specifies how the Measurement was
obtained - actual;
estimated; -- actual, estimated, or
static

r accuracy Enumeration Specifies the accuracy of the
measurement
measurement, if applicable applicable, as
0..10000
0..10000, indicating hundreds of
percent

H. PowerMeasurement (Class) inherits from and specializes
Measurement 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
current -- voltage, phase, and/or
frequencies for the
PowerMeasurement

I. EnergyMeasurement (Class) inherits from and specializes
Measurement Measurement:

r startTime Time Specifies the start time of the
EnergyMeasurement interval

r units "kWh" The units of measure for the energy - kilowatt hours --
kilowatt-hours

r provided Long A measurement of energy provided

r used Long A measurement of energy used /
consumed used/consumed

r produced Long A measurement of energy produced

r stored Long A measurement of energy stores stored

J. TimedMeasurement (Class) inherits from and specializes
Measurement 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

K. TimeInterval (Class) (Class):

r value Long a A value of time

r units Enumeration a A magnitude of time express time, expressed as seconds
with an SI prefix
(miliseconds etc) (milliseconds, etc.)

L. DemandMeasurement (Class) inherits from and specializes
Measurement 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; -- periodic, sliding,
or 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 A control to start or stop demand
measurement as -
active; -- active or inactive

r measurements[0.TimedMeasurement a measurements TimedMeasurement A collection of
.n] TimedMeasurements
[0..n] to compute demand

M. PowerStateSet (Class) (Class):

r powerSetIdentifier Integer an IANA assigned An IANA-assigned value indicating
a Power State Set

r name String A Power State Set name

r powerStates [0..n] PowerState a A set of Power States for the
[0..n] 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

N. PowerState (Class) (Class):

r powerStateIdentifier Integer an IANA assigned 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 PowerMeasurement 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
the last reset

r entryCount Long Indicates the number of
time
times the Energy Object
has entered or changed to
this state

O. PowerAttribute (Class) (Class):

r acQuality ACQuality Describes AC Power Attributes for
a Measurement

P. ACQuality (Class) (Class):

r acConfiguration Enumera Enumeration Describes the physical
tion
configuration of alternating
current as single phase (SNGL) three
phase (SNGL),
three-phase delta (DEL) (DEL), or three
phase
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 thdCurrent Long A calculated value for the current
Total Harmonic Distortion (THD).
The method of calculation is not
specified [IEC61850-7-4] 'ThdAmp'

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 percent, representing the
presumed accuracy of
active; reactive; 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-
4]
[IEC61850-7-4] 'TotVAr'

r totalApparentPower Long A measured value of the voltage
and current 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
[IEC61850-7-4] 'PF'

Q. DelPhase (Class) inherits from and specializes ACPhase ACQuality:

r phaseToNextPhas phaseToNext Long A measured value of phase to
eVoltage
PhaseVoltage 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 Total Harmonic Distortion
(THD) for phase to next phase. Method
The method of calculation is not
specified [IEC61850-7-4] 'ThdPPV'
R. WYEPhase (Class) inherits from and specializes ACPhase ACQuality:

r phaseToNeutral Long A measured value of phase to
Voltage neutral voltage [IEC61850-7-4]
'PhV'

r thdCurrent Long A measured calculated value for the current
Total Harmonic Distortion (THD).
The method of phase currents calculation is not
specified [IEC61850-7-4] 'A' 'ThdA'

r thdVoltage Long A calculated value of the voltage
total harmonic distortion (THD)
THD for phase to neutral [IEC61850-7-
4]
[IEC61850-7-4] 'ThdPhV'

r avgCurrent Long A measured value of phase currents
[IEC61850-7-4] 'A'

Authors' Addresses

John Parello
Cisco Systems, Inc.
3550 Cisco Way
San Jose, California CA 95134
US

Phone: +1 408 525 2339
Email:
EMail: jparello@cisco.com

Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
Diegem 1813
BE

Phone: +32 2 704 5622
Email:
EMail: bclaise@cisco.com

Brad Schoening
44 Rivers Edge Drive
Little Silver, NJ 07739
US

Phone:
Email:

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