summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7326.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7326.txt')
-rw-r--r--doc/rfc/rfc7326.txt3027
1 files changed, 3027 insertions, 0 deletions
diff --git a/doc/rfc/rfc7326.txt b/doc/rfc/rfc7326.txt
new file mode 100644
index 0000000..9271901
--- /dev/null
+++ b/doc/rfc/rfc7326.txt
@@ -0,0 +1,3027 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) J. Parello
+Request for Comments: 7326 B. Claise
+Category: Informational Cisco Systems, Inc.
+ISSN: 2070-1721 B. Schoening
+ Independent Consultant
+ J. Quittek
+ NEC Europe Ltd.
+ September 2014
+
+
+ Energy Management Framework
+
+Abstract
+
+ This document defines a framework for Energy Management (EMAN) for
+ devices and device components within, or connected to, communication
+ networks. The framework presents a physical reference model and
+ information model. The information model consists of an Energy
+ Management Domain as a set of Energy Objects. Each Energy Object can
+ be attributed with identity, classification, and context. Energy
+ Objects can be monitored and controlled with respect to power, Power
+ State, energy, demand, Power Attributes, and battery. Additionally,
+ the framework models relationships and capabilities between Energy
+ Objects.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7326.
+
+
+
+
+
+
+
+
+
+
+
+Parello, et al. Informational [Page 1]
+
+RFC 7326 EMAN Framework September 2014
+
+
+Copyright Notice
+
+ Copyright (c) 2014 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Terminology .....................................................4
+ 3. Target Devices ..................................................9
+ 4. Physical Reference Model .......................................10
+ 5. Areas Not Covered by the Framework .............................11
+ 6. Energy Management Abstraction ..................................12
+ 6.1. Conceptual Model ..........................................12
+ 6.2. Energy Object (Class) .....................................13
+ 6.3. Energy Object Attributes ..................................15
+ 6.4. Measurements ..............................................18
+ 6.5. Control ...................................................19
+ 6.6. Relationships .............................................25
+ 7. Energy Management Information Model ............................29
+ 8. Modeling Relationships between Devices .........................33
+ 8.1. Power Source Relationship .................................33
+ 8.2. Metering Relationship .....................................37
+ 8.3. Aggregation Relationship ..................................38
+ 9. Relationship to Other Standards ................................39
+ 10. Security Considerations .......................................39
+ 10.1. Security Considerations for SNMP .........................40
+ 11. IANA Considerations ...........................................41
+ 11.1. IANA Registration of New Power State Sets ................41
+ 11.2. Updating the Registration of Existing Power State Sets ...42
+ 12. References ....................................................43
+ 12.1. Normative References .....................................43
+ 12.2. Informative References ...................................44
+ 13. Acknowledgments ...............................................45
+ Appendix A. Information Model Listing .............................46
+
+
+
+
+
+
+Parello, et al. Informational [Page 2]
+
+RFC 7326 EMAN Framework September 2014
+
+
+1. Introduction
+
+ Network Management is often divided into the five main areas defined
+ in the ISO Telecommunications Management Network model: Fault,
+ Configuration, Accounting, Performance, and Security Management
+ (FCAPS) [X.700]. Not covered by this traditional management model is
+ Energy Management, which is rapidly becoming a critical area of
+ concern worldwide, as seen in [ISO50001].
+
+ This document defines an Energy Management framework for devices
+ within, or connected to, communication networks, per the Energy
+ Management requirements specified in [RFC6988]. The devices, or the
+ components of these devices (such as line cards, fans, and disks),
+ can then be monitored and controlled. Monitoring includes measuring
+ power, energy, demand, and attributes of power. Energy Control can
+ be performed by setting a device's or 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)
+
+ 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)
+
+ This framework further describes how to identify, classify, and
+ provide context for such devices. While context information is not
+ specific to Energy Management, some context attributes are specified
+ in the framework, addressing the following use cases:
+
+ o How important is a device in terms of its business impact?
+
+ o How should devices be grouped for reporting and searching?
+
+ o How should a device role be described?
+
+ Guidelines for using context for Energy Management are described.
+
+ The framework introduces the concept of a Power Interface that is
+ analogous to a network interface. A Power Interface is defined as an
+ interconnection among devices where energy can be provided, received,
+ or both.
+
+ The most basic example of Energy Management is a single device
+ reporting information about itself. In many cases, however, energy
+ is not measured by the device itself but is measured upstream in the
+ power distribution tree. For example, a Power Distribution Unit
+ (PDU) may measure the energy it supplies to attached devices and
+
+
+
+Parello, et al. Informational [Page 3]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ report this to an Energy Management System. Therefore, devices often
+ have relationships to other devices or components in the power
+ network. An Energy Management System (EnMS) generally requires an
+ understanding of the power topology (who provides power to whom), the
+ Metering topology (who meters whom), and the potential 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 power source, Metering, and Aggregation
+ Relationships.
+
+ The framework does not cover non-electrical 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 [RFC2119].
+
+ In this document, these words will appear with the above
+ interpretation only when in ALL CAPS. Lowercase uses of these words
+ are not to be interpreted as carrying the significance of RFC 2119
+ key words.
+
+ In this section, some terms have a NOTE that is not part of the
+ definition itself but accounts for differences between terminologies
+ of different standards organizations or further clarifies the
+ definition.
+
+ The terms are listed in an order that aids in reading where terms may
+ build off a previous term, as opposed to an alphabetical ordering.
+ Some terms that are common in electrical engineering or that describe
+ common physical items use a 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 devices use energy efficiently and appropriately
+ for the nature of the application and the cost constraints of the
+ organization.
+
+ Reference: Adapted from [TMN].
+
+
+
+
+
+
+
+Parello, et al. Informational [Page 4]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ NOTES:
+
+ 1. "Energy Management" refers to the activities, methods,
+ procedures, and tools that pertain to measuring, modeling,
+ planning, controlling, and optimizing the use of energy in
+ networked systems [NMF].
+
+ 2. Energy Management is a management domain 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, with the primary purpose of
+ 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 and action
+ plans, and take into account legal requirements related to
+ energy use. An ISO-EnMS allows organizations to improve energy
+ performance and demonstrate conformity to requirements,
+ standards, and/or legal requirements.
+
+ 2. Example ISO-EnMS: Company A defines a set of policies and
+ procedures indicating 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 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.
+
+
+
+
+
+Parello, et al. Informational [Page 5]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ Energy Control
+ Energy Control is a part of Energy Management that deals with
+ directing influence over devices.
+
+ electrical equipment
+ This is a general term 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].
+
+ non-electrical equipment (mechanical equipment)
+ This is a general term 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].
+
+ device
+ A device is a piece of electrical or non-electrical equipment.
+
+ Reference: Adapted from [IEEE100].
+
+ component
+ A component is a part of electrical or non-electrical equipment
+ (device).
+
+ Reference: Adapted from [TMN].
+
+ power inlet
+ A power inlet (or simply "inlet") is an interface at which a
+ device or component receives energy from another device or
+ component.
+
+ power outlet
+ A power outlet (or simply "outlet") is an interface at which a
+ device or component provides energy to another device or
+ component.
+
+ energy
+ 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 (kWh).
+
+ Reference: [IEEE100].
+
+
+
+
+
+Parello, et al. Informational [Page 6]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ NOTE:
+
+ 1. Energy is the capacity of a system to produce external activity
+ or perform work [ISO50001].
+
+ power
+ Power is the time rate at which energy is emitted, transferred, or
+ received; power is usually expressed in watts (joules per second).
+
+ Reference: [IEEE100].
+
+ demand
+ 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].
+
+ 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].
+
+ battery
+ A battery is one or more cells (consisting of an assembly of
+ electrodes, electrolyte, container, terminals, and (usually)
+ separators) that are a source and/or store of electric energy.
+
+ Reference: Adapted from [IEC60050].
+
+ Power Interface
+ A Power Interface is a power inlet, outlet, or both.
+
+
+
+
+
+Parello, et al. Informational [Page 7]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ Nameplate Power
+ The Nameplate Power is the nominal power of a device as specified
+ by the device manufacturer.
+
+ Power Attributes
+ Power Attributes are measurements of the electrical current,
+ voltage, phase, and frequencies at a given point in an electrical
+ power system.
+
+ Reference: Adapted from [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
+ "Power Quality" refers to characteristics of the electrical
+ current, voltage, phase, and frequencies at a given point in an
+ electric power system, evaluated against a set of reference
+ technical parameters. These parameters might, in some cases,
+ relate to the compatibility between electricity supplied in an
+ electric power system and the loads connected to that electric
+ power system.
+
+ Reference: [IEC60050].
+
+ NOTE:
+
+ 1. Electrical characteristics representing Power Quality
+ information are typically required by customer facility Energy
+ Management Systems. Electrical characteristics are not
+ intended to satisfy the detailed requirements of Power Quality
+ monitoring. Standards typically also give ranges of allowed
+ values; the information attributes are the raw measurements,
+ not the "yes/no" determination by the various standards.
+
+ Reference: [ASHRAE-201].
+
+
+
+
+
+
+
+
+
+
+
+
+Parello, et al. Informational [Page 8]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ Power State
+ A Power State is a condition or mode of a device (or component)
+ that broadly characterizes its capabilities, power, and
+ responsiveness to input.
+
+ Reference: Adapted from [IEEE1621].
+
+ Power State Set
+ A Power State Set is a collection of Power States that comprises a
+ named or logical control grouping.
+
+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 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, such as solar
+ cells, charging stations, or generators
+
+ o Power over Ethernet (PoE) endpoints
+
+ o Power Distribution Units (PDUs)
+
+ o Protocol gateway devices for Building Management Systems (BMS)
+
+
+
+
+Parello, et al. Informational [Page 9]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ 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 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:
+
+ +--------------------------+
+ | Energy Management System |
+ +--------------------------+
+ ^ ^
+ monitoring | | control
+ v v
+ +---------+
+ | device |
+ +---------+
+
+
+ Basic Power Supply:
+
+ +-----------------------------------------+
+ | Energy Management System |
+ +-----------------------------------------+
+ ^ ^ ^ ^
+ monitoring | | control monitoring | | control
+ v v v v
+ +--------------+ +-----------------+
+ | power source |########| device |
+ +--------------+ +-----------------+
+
+
+
+
+
+
+
+Parello, et al. Informational [Page 10]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ Single Power Supply with Multiple Devices:
+
+ +---------------------------------------+
+ | Energy Management System |
+ +---------------------------------------+
+ ^ ^ ^ ^
+ monitoring | | control monitoring | | control
+ v v v v
+ +--------+ +------------------+
+ | power |########| device 1 |
+ | source | # +------------------+-+
+ +--------+ #######| device 2 |
+ # +------------------+-+
+ #######| device 3 |
+ +------------------+
+
+
+ Multiple Power Supplies with Single Device:
+
+ +----------------------------------------------+
+ | Energy Management System |
+ +----------------------------------------------+
+ ^ ^ ^ ^ ^ ^
+ mon. | | ctrl. mon. | | ctrl. mon. | | ctrl.
+ v v v v v v
+ +----------+ +----------+ +----------+
+ | power |######| device |######| power |
+ | source 1 | | | | source 2 |
+ +----------+ +----------+ +----------+
+
+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 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 does not "convert to" or
+ "present as" an entity equivalent to electrical equipment is not
+ addressed.
+
+
+
+
+
+
+Parello, et al. Informational [Page 11]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ Energy Procurement and Manufacturing
+
+ While an EnMS may be a central point for corporate reporting, cost
+ computation, environmental impact analysis, and regulatory
+ compliance reporting, Energy Management in this framework excludes
+ energy procurement and the environmental impact of energy use.
+
+ As such, the framework does not include:
+
+ o Cost in currency or environmental units of manufacturing a
+ device
+
+ o Embedded carbon or environmental equivalences of a device
+
+ o Cost in currency or environmental impact to dismantle or
+ recycle a device
+
+ o Supply chain analysis of energy sources for device deployment
+
+ o Conversion of the usage or production of energy to units
+ expressed from the source of that energy (such as the
+ greenhouse gas emissions associated with the transfer of energy
+ from a diesel source)
+
+6. Energy Management Abstraction
+
+ This section describes a conceptual model of information that can be
+ used for Energy Management. The classes and categories of attributes
+ in the model are described, with a rationale for each.
+
+6.1. Conceptual Model
+
+ This section describes an information model that addresses issues
+ specific to Energy 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, and connections
+ between, devices and components.
+
+ This section defines a conceptual model for devices and components
+ 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.
+
+
+
+
+
+Parello, et al. Informational [Page 12]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ For modeling the devices and components, this section describes three
+ classes denoted by a "(Class)" suffix: a Device (Class), a Component
+ (Class), and a Power Interface (Class). These classes are sub-types
+ of an abstract Energy Object (Class).
+
+ Summary of Notation for Modeling Physical Equipment
+
+ Physical Modeling (Metadata) Model Instance
+ ---------------------------------------------------------
+ equipment Energy Object (Class) Energy Object
+
+ device Device (Class) Device
+
+ component Component (Class) Component
+
+ inlet/outlet Power Interface (Class) Power Interface
+
+ This section then describes the attributes of an Energy Object
+ (Class) for identification, classification, context, control, power,
+ and energy.
+
+ Since the interconnections between devices and components for Energy
+ Management may have no relation to the interconnections for Network
+ Management, the Energy Object (Classes) contain a separate
+ Relationships (Class) as an attribute to model these types of
+ interconnections.
+
+ The next sections describe each of the classes and categories of
+ attributes in the information model.
+
+ Not all of the attributes are mandatory for implementations.
+ Specifications describing implementations of the information model in
+ this framework need to be explicit about which are mandatory and
+ which are optional to implement.
+
+ The formal definitions of the classes and attributes are specified in
+ Section 7.
+
+6.2. Energy Object (Class)
+
+ An Energy Object (Class) represents a piece of equipment that is
+ part of, or attached to, a communications network that is monitored
+ or controlled or that aids in the management of another device for
+ Energy Management.
+
+
+
+
+
+
+
+Parello, et al. Informational [Page 13]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ The Energy Object (Class) is an abstract class that contains the base
+ attributes to represent a piece of equipment for Energy Management.
+ There are three types of Energy Object (Class): Device (Class),
+ Component (Class), and Power Interface (Class).
+
+6.2.1. Device (Class)
+
+ The Device (Class) is a 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 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 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Parello, et al. Informational [Page 14]
+
+RFC 7326 EMAN Framework September 2014
+
+
+6.3. Energy Object Attributes
+
+ This section describes categories of attributes for an Energy Object
+ (Class).
+
+6.3.1. Identification
+
+ A Universally Unique Identifier (UUID) [RFC4122] is used to uniquely
+ and persistently identify an Energy Object.
+
+ Every Energy Object has an optional unique human-readable printable
+ name. Possible naming conventions are textual DNS name, 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, 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 whether the Energy Object is primarily functioning as a
+ consumer, producer, meter, distributor, or store of energy.
+
+ Given the category and context of an object, an EnMS can summarize or
+ analyze measurements for the site.
+
+6.3.3. Context: Importance
+
+ An Energy Object can provide an importance value in the range of 1 to
+ 100 to help rank a device's use or relative value to the site. The
+ importance range is from 1 (least important) to 100 (most important).
+ The default importance value is 1.
+
+ For example, a typical office environment has several types of
+ phones, which can be rated according to their business impact. A
+ public desk phone has a lower importance (for example, 10) than a
+ business-critical emergency phone (for example, 100). As another
+ example, a company can consider that a PC and a phone for a customer
+ service engineer are more important than a PC and a phone for
+ lobby use.
+
+
+
+Parello, et al. Informational [Page 15]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ Although EnMS and administrators can establish their own ranking, the
+ following example is a broad recommendation for commercial
+ deployments [CISCO-EW]:
+
+ 90 to 100 Emergency response
+ 80 to 90 Executive or business-critical
+ 70 to 79 General or average
+ 60 to 69 Staff or support
+ 40 to 59 Public or guest
+ 1 to 39 Decorative or hospitality
+
+6.3.4. Context: Keywords
+
+ The Energy Object (Class) contains an attribute with context
+ keywords.
+
+ An Energy Object can provide a set of keywords that is a list of tags
+ that can be used for grouping, summary reporting (within or between
+ Energy Management Domains), and searching. Potential examples are
+ IT, lobby, HumanResources, Accounting, StoreRoom, CustomerSpace,
+ router, phone, floor2, or SoftwareLab.
+
+ The specifics of how this tag is represented are left to the MIB
+ module or other object definition documents to be based on this
+ framework.
+
+ There is no default value for a keyword. Multiple keywords can be
+ assigned to an Energy Object.
+
+6.3.5. Context: Role
+
+ The Energy Object (Class) contains a role attribute. The "role
+ description" string indicates the primary purpose the Energy Object
+ serves in the deployment. This could be a string representing the
+ purpose the Energy Object fulfills in the deployment.
+
+ The specifics of how this tag is represented are left to the MIB
+ module or other object definition documents to be based on this
+ framework.
+
+ Administrators can define any naming scheme for the role. As
+ guidance, a two-word role that combines the service the Energy Object
+ provides, along with type, can be used [IPENERGY].
+
+ Example types of devices: Router, Switch, Light, Phone, WorkStation,
+ Server, Display, Kiosk, HVAC.
+
+
+
+
+
+Parello, et al. Informational [Page 16]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ 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 meter that is not used by the utility to bill but is
+ instead used to get measurements from portions of a building.
+
+ The specifics of how this tag is represented are left to the MIB
+ module or other object definition documents to be based on this
+ framework.
+
+ An Energy Object MUST be a member of a single Energy Management
+ Domain; therefore, one attribute is provided.
+
+
+
+
+
+
+Parello, et al. Informational [Page 17]
+
+RFC 7326 EMAN Framework September 2014
+
+
+6.4. Measurements
+
+ The Energy Object (Class) contains attributes to describe power,
+ energy, and demand measurements.
+
+ An analogy for understanding power versus energy measurements can be
+ made to speed and distance in automobiles. Just as a speedometer
+ indicates the rate of change of distance (speed), a power measurement
+ indicates the rate of transfer of energy. The odometer in an
+ automobile measures the cumulative distance traveled; similarly, an
+ energy measurement indicates the accumulated energy transferred.
+
+ Demand measurements are averages of power measurements over time.
+ So, using the same analogy to an automobile: measuring the average
+ vehicle speed over multiple intervals of time for a given distance
+ 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 that
+ describes the nominal power as specified by the manufacturer of the
+ device. The EnMS can use the Nameplate Power for provisioning,
+ capacity planning, and (potentially) billing.
+
+ The Energy Object (Class) has attributes that describe the present
+ power information, along with how that measurement was obtained or
+ derived (e.g., actual, estimated, or static).
+
+ A power measurement is qualified with the units, magnitude, and
+ direction of power flow and is qualified as to the means by which the
+ measurement was made.
+
+ Power measurement magnitude conforms to the [IEC61850] definition of
+ unit multiplier for the SI (System International) units of measure.
+ Measured values are represented in SI units obtained by BaseValue *
+ (10 ^ Scale). For example, if current power usage of an Energy
+ Object is 17, it could be 17 W, 17 mW, 17 kW, or 17 MW, depending on
+ the value of the scaling factor. 17 W implies that BaseValue = 17
+ and Scale = 0, whereas 17 mW implies that BaseValue = 17 and
+ ScaleFactor = -3.
+
+
+
+
+
+Parello, et al. Informational [Page 18]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ An Energy Object (Class) indicates how the power measurement was
+ obtained with a caliber and accuracy attribute that indicates:
+
+ o Whether the measurements were made at the device itself or at a
+ remote source.
+
+ o Description of the method that was used to measure the power and
+ whether this method can distinguish actual or estimated values.
+
+ o Accuracy for actual measured values.
+
+6.4.2. Measurements: Power Attributes
+
+ The Energy Object (Class) contains an optional attribute that
+ describes Power Attribute information reflecting the electrical
+ characteristics of the measurement. These Power Attributes adhere to
+ the [IEC61850-7-2] standard for describing AC measurements.
+
+6.4.3. Measurements: Energy
+
+ The Energy Object (Class) contains optional attributes that represent
+ the energy used, received, produced, and/or stored. Typically, only
+ devices or components that can measure actual power will have the
+ ability to measure energy.
+
+6.4.4. Measurements: Demand
+
+ The Energy Object (Class) contains optional attributes that represent
+ demand information over time. Typically, only devices or components
+ that can report actual power are capable of measuring demand.
+
+6.5. Control
+
+ The Energy Object (Class) contains a Power State Set (Class)
+ attribute that represents the set of Power States a device or
+ component supports.
+
+ A Power State describes a condition or mode of a device or component.
+ While Power States are typically used for control, they may be used
+ for monitoring only.
+
+ A device or component is expected to support at least one set of
+ Power States consisting of at least two states: an on state and an
+ off state.
+
+ There are many existing standards describing device and component
+ Power States. The framework supports modeling a mixed set of Power
+ States defined in different standards. A basic example is given by
+
+
+
+Parello, et al. Informational [Page 19]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ the three Power States defined in IEEE1621 [IEEE1621]: on, off, and
+ sleep. The Distributed Management Task Force (DMTF) standards
+ organization [DMTF], 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:
+
+ a) The functionality provided by an Energy Object in this state.
+
+ b) A limitation of the power that an Energy Object uses in this
+ state.
+
+ c) A combination of a) and b).
+
+ The semantics of a Power State should be clearly defined. Limitation
+ (curtailment) of the power used by an Energy Object in a state may be
+ specified by:
+
+ o An absolute power value.
+
+ o A percentage value of power relative to the Energy Object's
+ Nameplate Power.
+
+ o An indication of power relative to another Power State. For
+ example, specify that power in state A is less than in state B.
+
+ o For supporting Power State management, an Energy Object provides
+ statistics on Power States, including the time an Energy Object
+ spent in a certain Power State and the number of times an Energy
+ Object entered a Power State.
+
+ When requesting an Energy Object to enter a Power State, an
+ indication of the Power State's name or number can be used.
+ Optionally, an absolute or percentage of Nameplate Power can be
+ provided to allow the Energy Object to transition to a nearest or
+ equivalent Power State.
+
+ When an Energy Object is set to a particular Power State, the
+ represented device or component may be busy. The Energy Object
+ should set the desired Power State and then update the actual Power
+ State when the device or component changes. There are then two Power
+ State (Class) control attributes: actual and requested.
+
+ The following sections describe well-known Power States for devices
+ and components that should be modeled in the information model.
+
+
+
+
+
+Parello, et al. Informational [Page 20]
+
+RFC 7326 EMAN Framework September 2014
+
+
+6.5.1. Power State Sets
+
+ There are several standards and implementations of Power State Sets.
+ The Energy Object (Class) supports modeling one or multiple Power
+ State Set implementations on the device or component concurrently.
+
+ There are currently three Power State Sets specified by IANA:
+
+ IEEE1621 (256) - [IEEE1621]
+ DMTF (512) - [DMTF]
+ EMAN (768) - [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.
+
+6.5.2. Power State Set: IEEE1621
+
+ The IEEE1621 Power State Set [IEEE1621] consists of three rudimentary
+ states: on, off, or sleep.
+
+ In IEEE1621, devices are limited to the three basic Power States --
+ on (2), sleep (1), and off (0). Any additional Power States are
+ variants of one of the basic states, rather than a fourth state
+ [IEEE1621].
+
+6.5.3. Power State Set: DMTF
+
+ The DMTF [DMTF] standards organization has defined a power profile
+ standard based on the CIM (Common Information Model), which consists
+ of 15 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].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Parello, et al. Informational [Page 21]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ The DMTF power profile extends ACPI Power States. The following
+ table provides a mapping between DMTF and ACPI Power State Sets:
+
+ DMTF ACPI
+ ------------------------------------------------
+ Reserved (0)
+ Reserved (1)
+ ON (2) G0/S0
+ Sleep-Light (3) G1/S1 G1/S2
+ Sleep-Deep (4) G1/S3
+ Power Cycle (Off-Soft) (5) G2/S5
+ Off-Hard (6) G3
+ Hibernate (Off-Soft) (7) G1/S4
+ Off-Soft (8) G2/S5
+ Power Cycle (Off-Hard) (9) G3
+ Master Bus Reset (10) G2/S5
+ Diagnostic Interrupt (11) G2/S5
+ Off-Soft Graceful (12) G2/S5
+ Off-Hard Graceful (13) G3
+ MasterBus Reset Graceful (14) G2/S5
+ Power Cycle Off-Soft Graceful (15) G2/S5
+ Power Cycle Off-Hard Graceful (16) G3
+
+6.5.4. Power State Set: IETF EMAN
+
+ The EMAN Power States are an expansion of the basic Power States as
+ defined in [IEEE1621] 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.
+
+
+
+
+
+
+
+
+Parello, et al. Informational [Page 22]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ The lowest non-operational state is 0, and the highest is 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 and may be mapped to [ACPI]
+ states P0 (maximum performance power) through P5 (minimum performance
+ and minimum power).
+
+ In each of the non-operational states (from mechoff(0) to ready(5)),
+ the Power State preceding it is expected to have a lower Power value
+ and a longer delay in returning to an operational state:
+
+ mechoff(0): An off state where no Energy Object features are
+ available. The Energy Object is unavailable. No energy is
+ being consumed, and the power connector can be removed.
+
+ softoff(1): Similar to mechoff(0), but some components remain
+ powered or receive trace power so that the Energy Object can be
+ awakened from its off state. In softoff(1), no context is
+ saved, and the device typically requires a complete boot when
+ awakened.
+
+ hibernate(2): No Energy Object features are available. The Energy
+ Object may be awakened without requiring a complete boot, but
+ the time for availability is longer than sleep(3). An example
+ for state hibernate(2) is a save-to-disk state where DRAM
+ context is not maintained. Typically, energy consumption is
+ zero or close to zero.
+
+ sleep(3): No Energy Object features are available, except for
+ out-of-band management, such as wake-up mechanisms. The time
+ for availability is longer than standby(4). An example for
+ state sleep(3) is a save-to-RAM state, where DRAM context is
+ maintained. Typically, energy consumption is close to zero.
+
+ standby(4): No Energy Object features are available, except for
+ out-of-band management, such as wake-up mechanisms. This mode
+ is analogous to cold-standby. The time for availability is
+ longer than ready(5). For example, processor context may not
+ be maintained. Typically, energy consumption is close to zero.
+
+ ready(5): No Energy Object features are available, except for
+ out-of-band management, such as wake-up mechanisms. This mode
+ is analogous to hot-standby. The Energy Object can be quickly
+ transitioned into an operational state. For example,
+ processors are not executing, but processor context is
+ maintained.
+
+
+
+
+
+Parello, et al. Informational [Page 23]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ 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): 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): 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): 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 tables:
+
+ Non-operational states:
+
+ IEEE1621 DMTF ACPI EMAN
+ --------------------------------------------------
+ off Off-Hard G3/S5 mechoff(0)
+ off Off-Soft G2/S5 softoff(1)
+ off Hibernate G1/S4 hibernate(2)
+ sleep Sleep-Deep G1/S3 sleep(3)
+ sleep Sleep-Light G1/S2 standby(4)
+ sleep Sleep-Light G1/S1 ready(5)
+
+
+
+
+
+
+
+
+
+
+
+
+Parello, et al. Informational [Page 24]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ Operational states:
+
+ IEEE1621 DMTF ACPI EMAN
+ ----------------------------------------------------
+ on on G0/S0/P5 lowMinus(6)
+ on on G0/S0/P4 low(7)
+ on on G0/S0/P3 mediumMinus(8)
+ on on G0/S0/P2 medium(9)
+ on on G0/S0/P1 highMinus(10)
+ on on G0/S0/P0 high(11)
+
+6.6. Relationships
+
+ The Energy Object (Class) contains a set of Relationship (Class)
+ attributes to model the relationships between devices and components.
+ Two Energy Objects can establish an Energy Object Relationship to
+ model the deployment topology with respect to Energy Management.
+
+ Relationships are modeled with a Relationship (Class) that contains
+ the UUID of the other participant in the relationship and a name that
+ describes the type of relationship [CHEN]. The types of
+ relationships are Power Source, Metering, and Aggregations.
+
+ o A Power Source Relationship is 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, 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, or Power Attributes of one or more
+ other Energy Objects. The Metering Relationship gives the view of
+ the Metering topology. Physical meters can be placed anywhere in
+ a power distribution tree. For example, utility meters monitor
+ and report accumulated power consumption of the entire building.
+ Logically, the Metering topology overlaps with the wiring
+ topology, as meters are connected to the wiring topology. A
+ typical example is meters that clamp onto the existing wiring.
+
+
+
+
+
+
+
+
+Parello, et al. Informational [Page 25]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ o An Aggregation Relationship is a relationship where one Energy
+ Object aggregates Energy Management information of one or more
+ other Energy Objects. The Aggregation Relationship gives a model
+ of devices that may aggregate (sum, average, etc.) values for
+ other devices. The Aggregation Relationship is slightly different
+ compared to the other relationships, as this refers more to a
+ management function.
+
+ In some situations, it is not possible to discover the Energy Object
+ Relationships, and an EnMS or administrator must set them. Given
+ that relationships can be assigned manually, the following sections
+ describe guidelines for use.
+
+6.6.1. Relationship Conventions and Guidelines
+
+ This Energy Management framework does not impose many "MUST" rules
+ related to Energy Object Relationships. There are always corner
+ cases that can be excluded by making stricter specifications for
+ relationships. However, the framework proposes a series of
+ guidelines, indicated with "SHOULD" and "MAY".
+
+6.6.2. Guidelines: Power Source
+
+ Power Source Relationships are intended to identify the connections
+ between Power Interfaces. This is analogous to a Layer 2 connection
+ in networking devices (a "one-hop connection").
+
+ The preferred modeling would be for Power Interfaces to participate
+ in Power Source Relationships. In some cases, Energy Objects may not
+ have the capability to model Power Interfaces. Therefore, a Power
+ Source Relationship can be established between two Energy Objects or
+ two non-connected Power Interfaces.
+
+ Strictly speaking, while components and Power Interfaces on the same
+ Device do provide or receive energy from each other, the Power Source
+ Relationship is intended to show energy transfer between Devices.
+ Therefore, the relationship is implied when on the same Device.
+
+ An Energy Object SHOULD NOT establish a Power Source Relationship
+ with a component.
+
+ o A Power Source Relationship SHOULD be established with the next
+ known Power Interface in the wiring topology.
+
+
+
+
+
+
+
+
+Parello, et al. Informational [Page 26]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ o The next known Power Interface in the wiring topology would be the
+ next device implementing the framework. In some cases, the domain
+ of devices under management may include some devices that do not
+ implement the framework. In these cases, the Power Source
+ Relationship can be established with the next device in the
+ topology that implements the framework and logically shows the
+ Power Source of the device.
+
+ o Transitive Power Source Relationships SHOULD NOT be established.
+ For example, if Energy Object A has a Power Source Relationship
+ "Poweredby" with Energy Object B, and if Energy Object B has a
+ Power Source Relationship "Poweredby" with Energy Object C, then
+ Energy Object A SHOULD NOT have a Power Source Relationship
+ "Poweredby" with 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 may include hardware that can measure power for
+ components, outlets, or the entire device. For example, some PDUs
+ may have the ability to measure power for each outlet and are
+ commonly referred to as metered-by-outlet. Others may be able to
+ control power at each power outlet but can only measure power at the
+ power inlet -- commonly referred to as metered-by-device.
+
+ While the Metering Relationship could be used to represent a device
+ as metered-by-outlet or metered-by-device, the Metering Relationship
+ SHOULD be used to model the relationship between a meter and all
+ devices covered by the meter downstream in the power distribution
+ system.
+
+ In general:
+
+ o A Metering Relationship MAY be established with any other Energy
+ Object, component, or Power Interface.
+
+ o Transitive Metering Relationships MAY be used.
+
+ o When there is a series of meters for one Energy Object, the Energy
+ Object MAY establish a Metering Relationship with one or more of
+ the meters.
+
+
+
+
+
+Parello, et al. Informational [Page 27]
+
+RFC 7326 EMAN Framework September 2014
+
+
+6.6.4. Guidelines: Aggregation
+
+ Aggregation Relationships are intended to identify when one device is
+ used to accumulate values from other devices. Typically, this is for
+ energy or power values among devices and not for components or Power
+ Interfaces on the same device.
+
+ The intent of Aggregation Relationships is to indicate when one
+ device is providing aggregate values for a set of other devices when
+ it is not obvious from the power source or simple containment within
+ a device.
+
+ Establishing Aggregation Relationships within the same device would
+ make modeling more complex, and the aggregated values can be implied
+ from the use of power inlets, outlet, and Energy Object values on the
+ same device.
+
+ Since an EnMS is naturally a point of Aggregation, it is not
+ necessary to model Aggregation for Energy Management Systems.
+
+ The Aggregation Relationship is intended for power and energy. It
+ MAY be used for Aggregation of other values from the information
+ model, but the rules and logical ability to aggregate each attribute
+ are out of scope for this document.
+
+ In general:
+
+ o A Device SHOULD NOT establish an Aggregation Relationship with
+ components contained on the same device.
+
+ o A Device SHOULD NOT establish an Aggregation Relationship with the
+ Power Interfaces contained on the same device.
+
+ o A Device SHOULD NOT establish an Aggregation Relationship with an
+ EnMS.
+
+ o Aggregators SHOULD log or provide notification in the case of
+ errors or missing values while performing Aggregation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Parello, et al. Informational [Page 28]
+
+RFC 7326 EMAN Framework September 2014
+
+
+6.6.5. Energy Object Relationship Extensions
+
+ This framework for Energy Management is based on three relationship
+ types: Aggregation, Metering, and Power Source.
+
+ This framework is defined with possible future extension of new
+ Energy Object Relationships in mind.
+
+ For example:
+
+ o Some Devices that may not be IP connected 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 could be modeled with an extension
+ called a "gang relationship", whose semantics would specify the
+ Energy Objects' grouping.
+
+7. Energy Management Information Model
+
+ This section presents an information model expression of the concepts
+ in this framework as a reference for implementers. The information
+ model is implemented as MIB modules in the different related IETF
+ EMAN documents. However, other programming structures with different
+ data models could be used as well.
+
+ Data modeling specifications of this information model may, where
+ needed, specify which attributes are required or optional.
+
+ Syntax
+
+ Unified Modeling
+ Language (UML)
+ Construct
+ [ISO-IEC-19501-2005] Equivalent Notation
+ -------------------- ----------------------------------
+ Notes // Notes
+
+ Class
+ (Generalization) CLASS name {member..}
+ Subclass
+ (Specialization) CLASS subclass
+ EXTENDS superclass {member..}
+ Class Member
+ (Attribute) attribute : type
+
+
+
+
+Parello, et al. Informational [Page 29]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ 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 : EnergyMeasurement
+ demand : DemandMeasurement
+
+ // control
+ powerControl [0..n] : PowerStateSet
+ }
+
+ CLASS PowerInterface EXTENDS EnergyObject {
+ eoIfType : enum { inlet, outlet, both }
+ }
+
+ CLASS Device EXTENDS EnergyObject {
+ eocategory : enum { producer, consumer, meter,
+ distributor, store }
+ powerInterfaces [0..n] : PowerInterface
+ components [0..n] : Component
+ }
+
+ CLASS Component EXTENDS EnergyObject {
+ eocategory : enum { producer, consumer, meter,
+ distributor, store }
+ powerInterfaces [0..n] : PowerInterface
+ components [0..n] : Component
+ }
+
+
+
+
+
+Parello, et al. Informational [Page 30]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ CLASS Nameplate {
+ nominalPower : PowerMeasurement
+ details : URI
+ }
+
+ CLASS Relationship {
+ relationshipType : enum { meters, meteredby, powers,
+ poweredby, aggregates, aggregatedby }
+ relationshipObject : uuid
+ }
+
+ CLASS Measurement {
+ multiplier : enum { -24..24 }
+ caliber : enum { actual, estimated, static }
+ accuracy : enum { 0..10000 } // hundreds of percent
+ }
+
+ CLASS PowerMeasurement EXTENDS Measurement {
+ value : long
+ units : "W"
+ powerAttribute : PowerAttribute
+ }
+
+ CLASS EnergyMeasurement EXTENDS Measurement {
+ startTime : time
+ units : "kWh"
+ provided : long
+ used : long
+ produced : long
+ stored : long
+
+ }
+
+ CLASS TimedMeasurement EXTENDS Measurement {
+ startTime : timestamp
+ value : Measurement
+ maximum : Measurement
+ }
+
+ CLASS TimeInterval {
+ value : long
+ units : enum { seconds, milliseconds,... }
+ }
+
+
+
+
+
+
+
+
+Parello, et al. Informational [Page 31]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ CLASS DemandMeasurement EXTENDS Measurement {
+ intervalLength : TimeInterval
+ intervals : long
+ intervalMode : enum { periodic, sliding, total }
+ intervalWindow : TimeInterval
+ sampleRate : TimeInterval
+ status : enum { active, inactive }
+ measurements [0..n] : TimedMeasurements
+ }
+
+ CLASS PowerStateSet {
+ powerSetIdentifier : int
+ name : string
+ powerStates [0..n] : PowerState
+ operState : int
+ adminState : int
+ reason : string
+ configuredTime : timestamp
+ }
+
+ CLASS PowerState {
+ powerStateIdentifier : int
+ name : string
+ cardinality : int
+ maximumPower : PowerMeasurement
+ totalTimeInState : time
+ entryCount : long
+ }
+
+ CLASS PowerAttribute {
+ acQuality : ACQuality
+ }
+
+ CLASS ACQuality {
+ acConfiguration : enum { SNGL, DEL, WYE }
+ avgVoltage : long
+ avgCurrent : long
+ thdCurrent : long
+ frequency : long
+ unitMultiplier : int
+ accuracy : int
+ totalActivePower : long
+ totalReactivePower : long
+ totalApparentPower : long
+ totalPowerFactor : long
+ }
+
+
+
+
+
+Parello, et al. Informational [Page 32]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ CLASS DelPhase EXTENDS ACQuality {
+ phaseToNextPhaseVoltage : long
+ thdVoltage : long
+ }
+
+ CLASS WYEPhase EXTENDS ACQuality {
+ phaseToNeutralVoltage : long
+ thdCurrent : long
+ thdVoltage : long
+ avgCurrent : long
+ }
+
+8. Modeling Relationships between Devices
+
+ In this section, we give examples of how to use the EMAN information
+ model to model physical topologies. Where applicable, we show how
+ the framework can be applied when devices can be modeled with Power
+ Interfaces. We also show how the framework can be applied when
+ devices cannot be modeled with Power Interfaces but only monitored or
+ 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 is used to model the interconnections
+ between devices, components, and/or Power Interfaces to indicate the
+ source of energy for a device.
+
+ In the following examples, we show variations on modeling the
+ reference topologies using relationships.
+
+ Given for all cases:
+
+ Device W: A computer with one power supply. Power Interface 1 is an
+ inlet for Device W.
+
+ Device X: A computer with two power supplies. Power Interface 1 and
+ Power Interface 2 are both inlets for Device X.
+
+ Device Y: A PDU with multiple Power Interfaces numbered 0..10. Power
+ Interface 0 is an inlet, and Power Interfaces 1..10 are outlets.
+
+ Device Z: A PDU with multiple Power Interfaces numbered 0..10. Power
+ Interface 0 is an inlet, and Power Interfaces 1..10 are outlets.
+
+
+
+
+
+
+Parello, et al. Informational [Page 33]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ 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 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 +------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Parello, et al. Informational [Page 34]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ 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 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 +------------+
+
+
+
+
+
+
+
+Parello, et al. Informational [Page 35]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ 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 Interfaces defined as inlets.
+
+ o Device Y would have an Energy Object representing the PDU
+ itself (the Device), with 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 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.
+ Devices Y and Z would both have respective Energy Objects
+ representing each entire PDU.
+
+
+
+
+
+
+
+
+Parello, et al. Informational [Page 36]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ The devices would have a Power Source Relationship such that:
+
+ Device X is powered by Device Y and powered by Device Z.
+
+ +----------+ poweredBy +------------+
+ | PDU Y |---------------------| Device X |
+ +----------+ powers +------------+
+
+ +----------+ poweredBy +------------+
+ | PDU Z |---------------------| Device X |
+ +----------+ powers +------------+
+
+8.2. Metering Relationship
+
+ A meter in a power distribution system can logically measure the
+ power or energy for all devices downstream from the meter in the
+ power distribution system. As such, a Metering Relationship can be
+ seen as a relationship between a meter and all of the devices
+ downstream from the meter.
+
+ We define in this case a Metering Relationship between a meter and
+ devices downstream from the meter.
+
+ +-----+---+ meteredBy +--------+ poweredBy +-------+
+ |Meter| PI|--------------| switch |-------------| phone |
+ +-----+---+ meters +--------+ powers +-------+
+ | |
+ | meteredBy |
+ +-------------------------------------------+
+ meters
+
+ In cases where the Power Source topology cannot be discovered or
+ derived from the information available in the Energy Management
+ Domain, the Metering topology can be used to relate the upstream
+ meter to the downstream devices in the absence of specific Power
+ Source Relationships.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Parello, et al. Informational [Page 37]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ 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 points for other devices. For
+ example, a PDU controller device may contain the summation of power
+ and energy readings for many PDU devices. The PDU controller will
+ have aggregate values for power and energy for a group of PDU
+ devices.
+
+ This Aggregation is independent of the physical power or
+ communication topology.
+
+ The functions that the Aggregation point may perform include the
+ calculation of values such as average, count, maximum, median,
+ minimum, or the listing (collection) of the Aggregation values, etc.
+
+ Based on IETF experience gained on Aggregations [RFC7015], the
+ Aggregation function in the EMAN framework is limited to the
+ summation.
+
+ When Aggregation occurs across a set of entities, values to be
+ aggregated may be missing for some entities. The EMAN framework does
+ not specify how these should be treated, as different implementations
+ may have good reason to take different approaches. One common
+ treatment is to define the Aggregation as missing if any of the
+
+
+
+Parello, et al. Informational [Page 38]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ 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 functions are out of the scope of
+ the EMAN framework but must be clearly specified by the equipment
+ vendor.
+
+9. Relationship to Other Standards
+
+ This Energy Management framework uses, as much as possible, existing
+ standards, especially with respect to information modeling and data
+ modeling [RFC3444].
+
+ The data model for power- and energy-related objects is based on
+ [IEC61850].
+
+ Specific examples include:
+
+ o The scaling factor, which represents Energy Object usage
+ magnitude, conforms to the [IEC61850] definition of unit
+ multiplier for the SI (System International) units of measure.
+
+ o The electrical 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:
+
+ - IEC 62053-22 and 60044-1 classes 0.1, 0.2, 0.5, 1, and 3.
+
+ - ANSI C12.20 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 definitions are based on the DMTF Power State
+ Profile and ACPI models, with operational state extensions.
+
+10. 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
+
+
+
+
+
+Parello, et al. Informational [Page 39]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ authorization, audit, and accounting principles to facilitate
+ investigations (compromise or benign misconfigurations) or any
+ reporting requirements.
+
+ The information and control capabilities specified in this framework
+ could be 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.
+
+ "User-based Security Model (USM) for version 3 of the Simple Network
+ Management Protocol (SNMPv3)" [RFC3414] presents a good description
+ of threats and mitigations for SNMPv3 that can be used as a guide for
+ implementations of this framework using other protocols.
+
+10.1. Security Considerations for SNMP
+
+ Readable objects in MIB modules (i.e., objects with a MAX-ACCESS
+ other than not-accessible) may be considered sensitive or vulnerable
+ in some network environments. It is important to control GET and/or
+ NOTIFY access to these objects and possibly to encrypt the values of
+ these objects when sending them over the network via SNMP.
+
+ The support for SET operations in a non-secure environment without
+ proper protection can have a negative effect on network operations.
+
+ For example:
+
+ o Unauthorized changes to the Energy Management Domain or business
+ context of a device will result in misreporting or interruption of
+ power.
+
+ o Unauthorized changes to a Power State will disrupt the power
+ settings of the different devices and therefore the state of
+ functionality of the respective devices.
+
+ o Unauthorized changes to the demand history will disrupt proper
+ accounting of energy usage.
+
+ With respect to data transport, SNMP versions prior to SNMPv3 did not
+ include adequate security. Even if the network itself is secure (for
+ example, by using IPsec), there is still no secure control over who
+ on the secure network is allowed to access and GET/SET
+ (read/change/create/delete) the objects in these MIB modules.
+
+ It is recommended that implementers consider the security features as
+ provided by the SNMPv3 framework (see [RFC3411]), including full
+ support for the SNMPv3 cryptographic mechanisms (for authentication
+ and confidentiality).
+
+
+
+Parello, et al. Informational [Page 40]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ 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.
+
+11. IANA Considerations
+
+11.1. IANA Registration of New Power State Sets
+
+ This document specifies an initial set of Power State Sets. The list
+ of these Power State Sets with their numeric identifiers is given 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 implementation of a Power State
+ Set shall not be adopted, since it would lead to proliferation of
+ Power State Sets.
+
+ Power States in a Power State Set are limited to 255 distinct values.
+ A new Power State Set must be assigned the next available numeric
+ identifier that is a multiple of 256.
+
+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, deprecation) for the IEEE1621 Power
+ State Set are administered by IANA through Expert Review [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
+ [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, deprecation) for the DMTF Power
+ State Set are administered by IANA through Expert Review [RFC5226].
+
+
+
+Parello, et al. Informational [Page 41]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ The group of experts must check for conformance with the DMTF
+ standard [DMTF] in addition to checking for completeness and accuracy
+ of the description.
+
+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, deprecation) for the EMAN Power
+ State Set are administered by IANA through Expert Review [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 Power State Sets, or to add or
+ deprecate some Power States within a Power State Set.
+
+ The registrant shall post an 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 regarding the deprecation of a
+ registration.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Parello, et al. Informational [Page 42]
+
+RFC 7326 EMAN Framework September 2014
+
+
+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.
+
+ [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
+ Architecture for Describing Simple Network Management
+ Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
+ December 2002.
+
+ [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
+ (USM) for version 3 of the Simple Network Management
+ Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
+
+ [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
+ Information Models and Data Models", RFC 3444,
+ January 2003.
+
+ [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
+ Unique IDentifier (UUID) URN Namespace", RFC 4122,
+ July 2005.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ May 2008.
+
+ [RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M.
+ Chandramouli, "Entity MIB (Version 4)", RFC 6933,
+ May 2013.
+
+ [RFC6988] Quittek, J., Ed., Chandramouli, M., Winter, R., Dietz, T.,
+ and B. Claise, "Requirements for Energy Management",
+ RFC 6988, September 2013.
+
+ [ISO-IEC-19501-2005]
+ ISO/IEC 19501:2005, Information technology, Open
+ Distributed Processing -- Unified Modeling Language (UML)
+ Version 1.4.2, January 2005.
+
+
+
+
+
+
+
+
+
+
+
+Parello, et al. Informational [Page 43]
+
+RFC 7326 EMAN Framework September 2014
+
+
+12.2. Informative References
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifier (URI): Generic Syntax", STD 66,
+ RFC 3986, January 2005.
+
+ [RFC7015] Trammell, B., Wagner, A., and B. Claise, "Flow Aggregation
+ for the IP Flow Information Export (IPFIX) Protocol",
+ RFC 7015, September 2013.
+
+ [ACPI] "Advanced Configuration and Power Interface
+ Specification", 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.
+
+ [NMF] Clemm, A., "Network Management Fundamentals",
+ ISBN-10: 1-58720-137-2, Cisco Press, November 2006.
+
+ [TMN] International Telecommunication Union, "TMN management
+ functions", ITU-T Recommendation M.3400, February 2000.
+
+ [IEEE100] "The Authoritative Dictionary of IEEE Standards Terms",
+ <http://ieeexplore.ieee.org/xpl/
+ mostRecentIssue.jsp?punumber=4116785>.
+
+ [ISO50001] "ISO 50001:2011 Energy management systems -- Requirements
+ with guidance for use", June 2011, <http://www.iso.org/>.
+
+ [IEC60050] "International Electrotechnical Vocabulary",
+ <http://www.electropedia.org/iev/iev.nsf/
+ welcome?openform>.
+
+ [IEC61850] "Power Utility Automation",
+ <http://www.iec.ch/smartgrid/standards/>.
+
+ [IEC61850-7-2]
+ "Abstract communication service interface (ACSI)",
+ <http://www.iec.ch/smartgrid/standards/>.
+
+ [IEC61850-7-4]
+ "Compatible logical node classes and data classes",
+ <http://www.iec.ch/smartgrid/standards/>.
+
+
+
+
+
+
+Parello, et al. Informational [Page 44]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ [DMTF] "Power State Management Profile", DMTF DSP1027
+ Version 2.0.0, December 2009,
+ <http://www.dmtf.org/sites/default/files/standards/
+ documents/DSP1027_2.0.0.pdf>.
+
+ [IPENERGY] Aldrich, R. and J. Parello, "IP-Enabled Energy Management:
+ A Proven Strategy for Administering Energy as a Service",
+ 2010, Wiley Publishing.
+
+ [X.700] CCITT Recommendation X.700, "Management framework for Open
+ Systems Interconnection (OSI) for CCITT applications",
+ September 1992.
+
+ [ASHRAE-201]
+ "ASHRAE Standard Project Committee 201 (SPC 201) Facility
+ Smart Grid Information Model",
+ <http://spc201.ashraepcs.org>.
+
+ [CHEN] Chen, P., "The Entity-Relationship Model: Toward a Unified
+ View of Data", ACM Transactions on Database Systems
+ (TODS), March 1976.
+
+ [CISCO-EW] Parello, J., Saville, R., and S. Kramling, "Cisco
+ EnergyWise Design Guide", Cisco Validated Design (CVD),
+ September 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,
+ which improved the text dramatically. Thanks to Rolf Winter for his
+ feedback, and to Bill Mielke for his feedback and very detailed
+ review. Thanks to Bruce Nordman for brainstorming, with numerous
+ conference calls and discussions. Finally, the authors would like to
+ thank the EMAN chairs: Nevil Brownlee, Bruce Nordman, and Tom Nadeau.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Parello, et al. Informational [Page 45]
+
+RFC 7326 EMAN Framework September 2014
+
+
+Appendix A. Information Model Listing
+
+ A. EnergyObject (Class):
+
+ r index Integer An [RFC6933] entPhysicalIndex
+
+ w name String An [RFC6933] entPhysicalName
+
+ r identifier uuid An [RFC6933] entPhysicalUUID
+
+ rw alternatekey String A manufacturer-defined string
+ that can be used to identify the
+ Energy Object
+
+ rw domainName String The name of an Energy Management
+ Domain for the Energy Object
+
+ rw role String An administratively assigned name
+ to indicate the purpose an
+ Energy Object serves in the
+ network
+
+ rw keywords String A list of keywords or [0..n] tags
+ that can be used to group Energy
+ Objects for reporting or
+ searching
+
+ rw importance Integer Specifies a ranking of how
+ important the Energy Object is
+ (on a scale of 1 to 100) compared
+ with other Energy Objects
+
+ rw relationships Relationship A list of 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 EnergyMeasurement The present energy measurement
+ for the Energy Object
+
+ r demand DemandMeasurement The present demand measurement
+ for the Energy Object
+
+
+
+Parello, et al. Informational [Page 46]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ r powerControl PowerStateSet A list of Power States Sets the
+ [0..n] Energy Object supports
+
+
+ B. PowerInterface (Class) inherits from EnergyObject:
+
+ r eoIfType Enumeration Indicates whether the Power
+ Interface is an inlet, outlet,
+ or both
+
+
+ C. Device (Class) inherits from EnergyObject:
+
+ rw eocategory Enumeration Broadly indicates whether
+ the Device is a producer,
+ consumer, meter, distributor,
+ or store of energy
+
+ r powerInterfaces PowerInterface A list of PowerInterfaces
+ [0..n] contained in this Device
+
+ r components Component A list of components
+ [0..n] contained in this Device
+
+
+ D. Component (Class) inherits from EnergyObject:
+
+ rw eocategory Enumeration Broadly indicates whether the
+ component is a producer,
+ consumer, meter, distributor, or
+ store of energy
+
+ r powerInterfaces PowerInterface A list of PowerInterfaces
+ [0..n] contained in this component
+
+ r components Component A list of components contained
+ [0..n] in this component
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Parello, et al. Informational [Page 47]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ E. Nameplate (Class):
+
+ r nominalPower PowerMeasurement The nominal power of the Energy
+ as specified by the device
+ manufacturer
+
+ rw details URI An [RFC3986] URI that links to
+ manufacturer information about
+ the nominal power of a device
+
+
+ F. Relationship (Class):
+
+ rw relationshipType Enumeration A description of the
+ relationship, indicating
+ 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):
+
+ r multiplier Enumeration The magnitude of the Measurement
+ in the range -24..24
+
+ r caliber Enumeration Specifies how the Measurement was
+ obtained -- actual, estimated, or
+ static
+
+ r accuracy Enumeration Specifies the accuracy of the
+ measurement, if applicable, as
+ 0..10000, indicating hundreds of
+ percent
+
+
+ H. PowerMeasurement (Class) inherits from Measurement:
+
+ r value Long A measurement value of
+ power
+
+ r units "W" The units of measure for
+ the power -- "Watts"
+
+
+
+
+Parello, et al. Informational [Page 48]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ r powerAttribute PowerAttribute Measurement of the electrical
+ current -- voltage, phase, and/or
+ frequencies for the
+ PowerMeasurement
+
+
+ I. EnergyMeasurement (Class) inherits from Measurement:
+
+ r startTime Time Specifies the start time of the
+ EnergyMeasurement interval
+
+ r units "kWh" The units of measure for the energy --
+ kilowatt-hours
+
+ r provided Long A measurement of energy provided
+
+ r used Long A measurement of energy used/consumed
+
+ r produced Long A measurement of energy produced
+
+ r stored Long A measurement of energy stored
+
+
+ J. TimedMeasurement (Class) inherits from 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):
+
+ r value Long A value of time
+
+ r units Enumeration A magnitude of time, expressed as seconds
+ with an SI prefix (milliseconds, etc.)
+
+
+ L. DemandMeasurement (Class) inherits from 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
+
+
+
+Parello, et al. Informational [Page 49]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ rw intervalMode Enumeration The mode of interval
+ measurement -- 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 control to start or stop demand
+ measurement -- active or inactive
+
+ r measurements TimedMeasurement A collection of TimedMeasurements
+ [0..n] to compute demand
+
+
+ M. PowerStateSet (Class):
+
+ r powerSetIdentifier Integer An IANA-assigned value indicating
+ a Power State Set
+
+ r name String A Power State Set name
+
+ r powerStates PowerState 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):
+
+ r powerStateIdentifier Integer An IANA-assigned value
+ indicating a Power State
+
+ r name String A name for the Power State
+
+
+
+
+Parello, et al. Informational [Page 50]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ r cardinality Integer A value indicating an
+ ordering of the Power State
+
+ rw maximumPower PowerMeasurement Indicates the maximum 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
+ times the Energy Object
+ has entered or changed to
+ this state
+
+
+ O. PowerAttribute (Class):
+
+ r acQuality ACQuality Describes AC Power Attributes for
+ a Measurement
+
+ P. ACQuality (Class):
+
+ r acConfiguration Enumeration Describes the physical
+ configuration of alternating
+ current as single phase (SNGL),
+ three-phase delta (DEL), or
+ three-phase Y (WYE)
+
+ r avgVoltage Long The average of the voltage measured
+ over an integral number of AC
+ cycles [IEC61850-7-4] 'Vol'
+
+ r avgCurrent Long The current per phase
+ [IEC61850-7-4] 'Amp'
+
+ r 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
+
+
+
+Parello, et al. Informational [Page 51]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ r accuracy Integer Percentage value in 100ths
+ of a percent, representing the
+ presumed accuracy of active,
+ reactive, and apparent power
+ in this instance
+
+ r totalActivePower Long A measured value of the actual
+ power delivered to or consumed by
+ the load [IEC61850-7-4] 'TotW'
+
+ r totalReactivePower Long A measured value of the reactive
+ portion of the apparent power
+ [IEC61850-7-4] 'TotVAr'
+
+ r totalApparentPower Long A measured value of the voltage
+ and current, which determines the
+ apparent power as the vector sum of
+ real and reactive power
+ [IEC61850-7-4] 'TotVA'
+
+ r totalPowerFactor Long A measured value of the ratio of
+ the real power flowing to the load
+ versus the apparent power
+ [IEC61850-7-4] 'TotPF'
+
+
+ Q. DelPhase (Class) inherits from ACQuality:
+
+ r phaseToNext Long A measured value of phase to
+ PhaseVoltage next phase voltages where the
+ next phase is [IEC61850-7-4]
+ 'PPV'
+
+ r thdVoltage Long A calculated value for the
+ voltage Total Harmonic Distortion
+ (THD) for phase to next phase.
+ The method of calculation is not
+ specified [IEC61850-7-4] 'ThdPPV'
+
+
+
+
+
+
+
+
+
+
+
+
+
+Parello, et al. Informational [Page 52]
+
+RFC 7326 EMAN Framework September 2014
+
+
+ R. WYEPhase (Class) inherits from ACQuality:
+
+ r phaseToNeutral Long A measured value of phase to
+ Voltage neutral voltage [IEC61850-7-4]
+ 'PhV'
+
+ r thdCurrent Long A calculated value for the current
+ Total Harmonic Distortion (THD).
+ The method of calculation is not
+ specified [IEC61850-7-4] 'ThdA'
+
+ r thdVoltage Long A calculated value of the voltage
+ THD for phase to neutral
+ [IEC61850-7-4] 'ThdPhV'
+
+ r avgCurrent Long A measured value of phase currents
+ [IEC61850-7-4] 'A'
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Parello, et al. Informational [Page 53]
+
+RFC 7326 EMAN Framework September 2014
+
+
+Authors' Addresses
+
+ John Parello
+ Cisco Systems, Inc.
+ 3550 Cisco Way
+ San Jose, CA 95134
+ US
+
+ Phone: +1 408 525 2339
+ EMail: jparello@cisco.com
+
+
+ Benoit Claise
+ Cisco Systems, Inc.
+ De Kleetlaan 6a b1
+ Diegem 1813
+ BE
+
+ Phone: +32 2 704 5622
+ EMail: bclaise@cisco.com
+
+
+ Brad Schoening
+ 44 Rivers Edge Drive
+ Little Silver, NJ 07739
+ US
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+Parello, et al. Informational [Page 54]
+