[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

    Network Working Group                             J. Parello
    Internet-Draft                                     B. Claise
    Intended Status: Informational           Cisco Systems, Inc.
    Expires: October 28, 2014                       B. Schoening
                                          Independent Consultant
                                                      J. Quittek
                                                  NEC Europe Ltd
    
                                                  April 28, 2014
    
    
                       Energy Management Framework
                       draft-ietf-eman-framework-19
    
    
    Status of this Memo
    
       This Internet-Draft is submitted in full conformance with
       the provisions of BCP 78 and BCP 79.
    
       Internet-Drafts are working documents of the Internet
       Engineering Task Force (IETF), its areas, and its working
       groups.  Note that other groups may also distribute working
       documents as Internet-Drafts.
    
       Internet-Drafts are draft documents valid for a maximum of
       six months and may be updated, replaced, or obsoleted by
       other documents at any time.  It is inappropriate to use
       Internet-Drafts as reference material or to cite them other
       than as "work in progress."
    
       The list of current Internet-Drafts can be accessed at
       http://www.ietf.org/ietf/1id-abstracts.txt
    
       The list of Internet-Draft Shadow Directories can be
       accessed at http://www.ietf.org/shadow.html
    
       This Internet-Draft will expire on October 2 2014.
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    Claise, et al         Expires October 28, 2014       [Page 1]
    

    Internet-Draft             EMAN Framework          April 2014
    
    Copyright Notice
    
       Copyright (c) 2014 IETF Trust and the persons identified as
       the document authors. All rights reserved.
    
       This document is subject to BCP 78 and the IETF Trust's
       Legal Provisions Relating to IETF Documents
       (http://trustee.ietf.org/license-info) in effect on the
       date of publication of this document. Please review these
       documents carefully, as they describe your rights and
       restrictions with respect to this document. Code Components
       extracted from this document must include Simplified BSD
       License text as described in Section 4.e of the Trust Legal
       Provisions and are provided without warranty as described
       in the Simplified BSD License.
    
    Abstract
    
       This document defines a framework for Energy Management for
       devices and device components within or connected to
       communication networks.  The framework presents a physical
       reference model and information model. The information
       model consists of an Energy Management Domain as a set of
       Energy Objects. Each Energy Object can be attributed with
       identity, classification, and context.  Energy Objects can
       be monitored and controlled with respect to power, Power
       State, energy, demand, Power Attributes, and battery.
       Additionally the framework models relationships and
       capabilities between Energy Objects.
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    Claise, et al.        Expires October 28, 2014      [Page 2]
    
    Internet-Draft             EMAN Framework          April 2014
    
    Table of Contents
    
       1. Introduction .............................................. 3
       2. Terminology ............................................... 4
       3. Target Devices ............................................ 10
       4. Physical Reference Model .................................. 11
       5. Not Covered by the Framework .............................. 12
       6. Energy Management Abstraction ............................. 13
          6.1. Conceptual Model ..................................... 13
          6.2. Energy Object (Class) ................................ 14
          6.3. Energy Object Attributes ............................. 15
          6.4. Measurements ......................................... 18
          6.5. Control .............................................. 20
          6.6. Relationships ........................................ 26
       7. Energy Management Information Model ....................... 30
       8. Modeling Relationships between Devices .................... 34
          8.1. Power Source Relationship ............................ 34
          8.2. Metering Relationship ................................ 38
          8.3. Aggregation Relationship ............................. 39
       9. Relationship to Other Standards ........................... 40
       10. Implementation Status .................................... 40
       11. Security Considerations .................................. 41
          11.1. Security Considerations for SNMP .................... 41
       12. IANA Considerations....................................... 42
          12.1. IANA Registration of new Power State Sets ........... 42
          12.2. Updating the Registration of Existing Power State
          Sets ...................................................... 44
       13. References ............................................... 44
       14. Acknowledgments .......................................... 47
       Appendix A. Information Model Listing ........................ 47
       Authors' Addresses ........................................... 56
    
    1. Introduction
    
       Network management is often divided into the five main
       areas defined in the ISO Telecommunications Management
       Network model: Fault, Configuration, Accounting,
       Performance, and Security Management (FCAPS) [X.700].  Not
       covered by this traditional management model is Energy
       Management, which is rapidly becoming a critical area of
       concern worldwide, as seen in [ISO50001].
    
       This document defines an Energy Management framework for
    

       devices within or connected to communication networks, per
       the Energy Management requirements specified in [RFC6988].
       The devices or components of these devices (such as line
       cards, fans, and disks) can then be monitored and
       controlled.  Monitoring includes measuring power, energy,
       demand, and attributes of power.  Energy control can be
    
    
    Claise, et al.        Expires October 28, 2014      [Page 3]
    

    Internet-Draft             EMAN Framework          April 2014
    
       performed by setting a devices' or components' state. The
       devices monitored by this framework can be either consumers
       of energy (such as routers and computer systems) and
       components of such devices (such as line cards, fans, and
       disks), or they can be producers of energy (like an
       uninterruptible power supply or renewable energy system)
       and their associated components (such as battery cells,
       inverters, or photovoltaic panels).
    
       This framework further describes how to identify, classify
       and provide context for such devices.  While context
       information is not specific to Energy Management, some
       context attributes are specified in the framework,
       addressing the following use cases: how important is a
       device in terms of its business impact, how should devices
       be grouped for reporting and searching, and how should a
       device role be described. Guidelines for using context for
       Energy Management are described.
    
       The framework introduces the concept of a Power Interface
       that is analogous to a network interface. A Power Interface
       is defined as an interconnection among devices where energy
       can be provided, received, or both.
    
       The most basic example of Energy Management is a single
       device reporting information about itself.  In many cases,
       however, energy is not measured by the device itself, but
       measured upstream in the power distribution tree.  For
       example, a power distribution unit (PDU) may measure the
       energy it supplies to attached devices and report this to
       an energy management system.  Therefore, devices often have
       relationships to other devices or components in the power
       network.  An EnMS (Energy Management System) generally
       requires an understanding of the power topology (who
       provides power to whom), the metering topology (who meters
       whom), and an understanding of the potential aggregation
       (who aggregates values of others).
    
       The relationships build on the Power Interface concept. The
       different relationships among devices and components,
       specified in this document, include: power source,
       metering, and aggregation relationships.
    
       The framework does not cover non-electrical equipment nor
       does it cover energy procurement and manufacturing.
    
    2. Terminology
    
    
    
    
    Claise, et al.        Expires October 28, 2014      [Page 4]
    

    Internet-Draft             EMAN Framework          April 2014
    
       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
       "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
       and "OPTIONAL" in this document are to be interpreted as
       described in RFC-2119 [RFC2119].
    
       In this document these words will appear with that
       interpretation only when in ALL CAPS. Lower case uses of
       these words are not to be interpreted as carrying RFC-2119
       significance.
    
       In this section some terms have a NOTE that is not part of
       the definition itself, but accounts for differences between
       terminologies of different standards organizations or
       further clarifies the definition.
    
       The terms are listing in an order that aids in reading
       where terms may build off a previous term as opposed to an
       alphabetical ordering. Some terms that are common in
       electrical engineering or that describe common physical
       items use a lower case notation.
    
       Energy Management
         Energy Management is a set of functions for measuring,
         modeling, planning, and optimizing networks to ensure
         that the network and network attached devices use energy
         efficiently and appropriately for the nature of the
         application and the cost constraints of the organization.
    
         Reference: Adapted from [ITU-T-M-3400]
    
         NOTES:
         1. Energy Management refers to the activities, methods,
         procedures and tools that pertain to measuring, modeling,
         planning, controlling and optimizing the use of energy in
         networked systems [NMF].
    
         2. Energy Management is a management domain which is
         congruent to any of the FCAPS areas of management in the
         ISO/OSI Network Management Model [TMN]. Energy Management
         for communication networks and attached devices is a
         subset or part of an organization's greater Energy
         Management Policies.
    
       Energy Management System (EnMS)
         An Energy Management System is a combination of hardware
         and software used to administer a network with the
         primary purpose of energy management.
    
         NOTES:
    
    
    Claise, et al.        Expires October 28, 2014      [Page 5]
    

    Internet-Draft             EMAN Framework          April 2014
    
         1. An Energy Management System according to [ISO50001]
         (ISO-EnMS) is a set of systems or procedures upon which
         organizations can develop and implement an energy policy,
         set targets, action plans and take into account legal
         requirements related to energy use.  An ISO-EnMS allows
         organizations to improve energy performance and
         demonstrate conformity to requirements, standards, and/or
         legal requirements.
    
         2. Example ISO-EnMS:  Company A defines a set of policies
         and procedures indicating there should exist multiple
         computerized systems that will poll energy measurements
         from their meters and pricing / source data from their
         local utility. Company A specifies that their CFO (Chief
         Financial Officer) should collect information and
         summarize it quarterly to be sent to an accounting firm
         to produce carbon accounting reporting as required by
         their local government.
    
         3. For the purposes of EMAN, the definition herein is the
         preferred meaning of an Energy Management System (EnMS).
         The definition from [ISO50001] can be referred to as ISO
         Energy Management System (ISO-EnMS).
    
       Energy Monitoring
         Energy Monitoring is a part of Energy Management that
         deals with collecting or reading information from devices
         to aid in Energy Management.
    
       Energy Control
         Energy Control is a part of Energy Management that deals
         with directing influence over devices.
    
       electrical equipment
         A general term including materials, fittings, devices,
         appliances, fixtures, apparatus, machines, etc., used as
         a part of, or in connection with, an electric
         installation.
         Reference: [IEEE100]
    
       non-electrical equipment (mechanical equipment)
         A general term including materials, fittings, devices,
         appliances, fixtures, apparatus, machines, etc., used as
         a part of, or in connection with, non-electrical power
         installations.
    
         Reference: Adapted from [IEEE100]
    
       device
    
    
    Claise, et al.        Expires October 28, 2014      [Page 6]
    

    Internet-Draft             EMAN Framework          April 2014
    
         A piece of electrical or non-electrical equipment.
    
         Reference: Adapted from [IEEE100]
    
       component
         A part of an electrical or non-electrical equipment
         (device).
    
         Reference: Adapted from [ITU-T-M-3400]
    
       power inlet
         A power inlet (or simply inlet) is an interface at which
         a device or component receives energy from another device
         or component.
    
       power outlet
         A power outlet (or simply outlet) is an interface at
         which a device or component provides energy to another
         device or component.
    
       energy
         That which does work or is capable of doing work. As used
         by electric utilities, it is generally a reference to
         electrical energy and is measured in kilowatt hours
         (kWh).
    
         Reference: [IEEE100]
    
         NOTES
         1. Energy is the capacity of a system to produce external
         activity or perform work [ISO50001]
    
       power
         The time rate at which energy is emitted, transferred, or
         received; usually expressed in watts (joules per second).
    
         Reference: [IEEE100]
    
       demand
         The average value of power or a related quantity over a
         specified interval of time. Note: Demand is expressed in
         kilowatts, kilovolt-amperes, kilovars, or other suitable
         units.
    
         Reference: [IEEE100]
    
         NOTES:
         1. While IEEE100 defines demand in kilo measurements, for
         EMAN we use watts with any suitable metric prefix.
    
    
    Claise, et al.        Expires October 28, 2014      [Page 7]
    

    Internet-Draft             EMAN Framework          April 2014
    
    
       provide energy
         A device (or component) "provides" energy to another
         device if there is an energy flow from this device to the
         other one.
    
       receive energy
         A device (or component) "receives" energy from another
         device if there is an energy flow from the other device
         to this one.
    
       meter (energy meter)
         a device intended to measure electrical energy by
         integrating power with respect to time.
    
         Reference: Adapted from [IEC60050]
    
       battery
         one or more cells (consisting of an assembly of
         electrodes, electrolyte, container, terminals and usually
         separators)  that are a source and/or store of electric
         energy.
    
         Reference: Adapted from [IEC60050]
    
       Power Interface
         A power inlet, outlet, or both.
    
       Nameplate Power
         The Nameplate Power is the nominal power of a device as
         specified by the device manufacturer.
    
       Power Attributes
         Measurements of the electrical current, voltage, phase
         and frequencies at a given point in an electrical power
         system.
         Reference: Adapted from [IEC60050]
    
         NOTES:
         1. Power Attributes are not intended to provide any
            bounds or recommended range for the value. They are
            simply the reading of the value associated with the
            attribute in question.
    
       Power Quality
         Characteristics of the electrical current, voltage, phase
         and frequencies at a given point in an electric power
         system, evaluated against a set of reference technical
         parameters. These parameters might, in some cases, relate
    
    
    Claise, et al.        Expires October 28, 2014      [Page 8]
    

    Internet-Draft             EMAN Framework          April 2014
    
         to the compatibility between electricity supplied in an
         electric power system and the loads connected to that
         electric power system.
    
         Reference: [IEC60050]
    
         NOTES:
         1. Electrical characteristics representing power quality
         information are typically required by customer facility
         energy management systems. It is not intended to satisfy
         the detailed requirements of power quality monitoring.
         Standards typically also give ranges of allowed values;
         the information attributes are the raw measurements, not
         the "yes/no" determination by the various standards.
    
         Reference: [ASHRAE-201]
    
       Power State
         A Power State is a condition or mode of a device (or
         component) that broadly characterizes its capabilities,
         power, and responsiveness to input.
    
         Reference: Adapted from [IEEE1621]
    
       Power State Set
         A Power State Set is a collection of Power States that
         comprises a named or logical control grouping.
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    Claise, et al.        Expires October 28, 2014      [Page 9]
    

    Internet-Draft             EMAN Framework          April 2014
    
    3. Target Devices
    
       With Energy Management, there exists a wide variety of
       devices that may be contained in the same deployment as a
       communication network but comprise a separate facility,
       home, or power distribution network.
    
       Energy Management has special challenges because a power
       distribution network supplies energy to devices and
       components, while a separate communications network
       monitors and controls the power distribution network.
    
       The target devices for Energy Management are all devices
       that can be monitored or controlled (directly or
       indirectly) by an Energy Management System (EnMS). These
       target devices include, for example:
             . Simple electrical appliances and fixtures
             . Hosts, such as a PC, a server, or a printer
             . Switches, routers, base stations, and other network
               equipment and middle boxes
             . Components within devices, a line card inside a
               switch
             . Batteries as a device or component that is a store
               of energy
             . Devices or components that charge or produce energy
               such as solar cells, charging stations or
               generators
             . Power over Ethernet (PoE) endpoints
             . Power Distribution Units (PDU)
             . Protocol gateway devices for Building Management
               Systems (BMS)
             . Electrical meters
             . Sensor controllers with subtended sensors
    
       Target devices include devices that communicate via the
       Internet Protocol (IP) as well as devices using other means
       for communication. The latter are managed through gateways
       or proxies that can communicate using IP.
    
    
    
    
    
    
    
    
    
    
    
    
    Claise, et al.        Expires October 28, 2014     [Page 10]
    

    Internet-Draft             EMAN Framework          April 2014
    
    4. Physical Reference Model
    
       The following reference model describes physical power
       topologies that exist in parallel to a communication
       topology. While many more topologies can be created with
       combination of devices, the following are some basic ones
       that show how Energy Management topologies differ from
       Network Management topologies.
    
       NOTE: "###" is used to denote a transfer of energy.
              - >  is used to denote a transfer of information.
    
      Basic Energy Management
    
                              +--------------------------+
                              | Energy Management System |
                              +--------------------------+
                                          ^  ^
                               monitoring |  | control
                                          v  v
                                      +---------+
                                      | device  |
                                      +---------+
    
      Basic Power Supply
    
                   +-----------------------------------------+
                   |         Energy Management System        |
                   +-----------------------------------------+
                         ^  ^                       ^  ^
              monitoring |  | control    monitoring |  | control
                         v  v                       v  v
                   +--------------+        +-----------------+
                   | power source |########|      device     |
                   +--------------+        +-----------------+
    
      Single Power Supply with Multiple Devices
    
                     +---------------------------------------+
                     |       Energy Management System        |
                     +---------------------------------------+
                        ^  ^                       ^  ^
             monitoring |  | control    monitoring |  | control
                        v  v                       v  v
                     +--------+        +------------------+
                     | power  |########|         device 1 |
                     | source |   #    +------------------+-+
                     +--------+   #######|         device 2 |
                                    #    +------------------+-+
    
    
    Claise, et al.        Expires October 28, 2014     [Page 11]
    

    Internet-Draft             EMAN Framework          April 2014
    
                                    #######|         device 3 |
                                           +------------------+
    
      Multiple Power Supplies with Single Devices
    
            +----------------------------------------------+
            |          Energy Management System            |
            +----------------------------------------------+
                ^  ^              ^  ^              ^  ^
           mon. |  | ctrl.   mon. |  | ctrl.   mon. |  | ctrl.
                v  v              v  v              v  v
            +----------+      +----------+      +----------+
            | power    |######|  device  |######| power    |
            | source 1 |      |          |      | source 2 |
            +----------+      +----------+      +----------+
    
    
    
    5. Not Covered by the Framework
    
       While this framework is intended as a framework for Energy
       Management in general, there are some areas that are not
       covered.
    
      Non-Electrical Equipment
    
       The primary focus of this framework is the management of
       electrical equipment. Non-Electrical equipment, not covered
       in this framework, could nevertheless be modeled by
       providing interfaces that comply with the framework: for
       example, using the same units for power and energy.
       Therefore, non-electrical equipment that do not convert-to
       or present-as equivalent to electrical equipment are not
       addressed.
    
      Energy Procurement and Manufacturing
    
       While an EnMS may be a central point for corporate
       reporting, cost computation, environmental impact analysis,
       and regulatory compliance reporting - Energy Management in
       this framework excludes energy procurement and the
       environmental impact of energy use.
    
       As such the framework does not include:
          o Cost in currency or environmental units of
             manufacturing a device.
          o Embedded carbon or environmental equivalences of a
             device
    
    
    
    Claise, et al.        Expires October 28, 2014     [Page 12]
    

    Internet-Draft             EMAN Framework          April 2014
    
          o Cost in currency or environmental impact to dismantle
             or recycle a device.
          o Supply chain analysis of energy sources for device
             deployment
          o Conversion of the usage or production of energy to
             units expressed from the source of that energy (such
             as the greenhouse gas emissions associated the
             transfer of energy from a diesel source).
    
    6. Energy Management Abstraction
    
       This section describes a conceptual model of information
       that can be used for Energy Management. The classes and
       categories of attributes in the model are described with
       rationale for each.
    
    6.1. Conceptual Model
    
       This section describes an information model that addresses
       issues specific to Energy Management, which complements
       existing Network Management models.
    
       An information model for Energy Management will need to
       describe a means to monitor and control devices and
       components. The model will also need to describe the
       relationships among and connections between devices and
       components.
    
       This section defines a similar conceptual model for devices
       and components to that used in Network Management: devices,
       components, and interfaces. This section then defines the
       additional attributes specific to Energy Management for
       those entities that are not available in existing Network
       Management models.
    
       For modeling the devices and components this section
       describes three classes denoted by a "(Class)" suffix:  a
       Device (Class), a Component (Class), and a Power Interface
       (Class). These classes are sub-types of an abstract Energy
       Object (Class).
    
           Summary of Notation for Modeling Physical Equipment
    
       Physical         Modeling (Meta Data)     Model Instance
       ---------------------------------------------------------
       equipment        Energy Object (Class)    Energy Object
       device           Device (Class)           Device
       component        Component (Class)        Component
       inlet / outlet   Power Interface (Class)  Power Interface
    
    
    Claise, et al.        Expires October 28, 2014     [Page 13]
    

    Internet-Draft             EMAN Framework          April 2014
    
    
    
       This section then describes the attributes of an Energy
       Object (Class) for identification, classification, context,
       control, power and energy.
    
       Since the interconnections between devices and components
       for Energy Management may have no relation to the
       interconnections for Network Management the Energy Object
       (Classes) contain a separate Relationships (Class) as an
       attribute to model these types of interconnections.
    
       The next sections describe the each of the classes and
       categories of attributes in the information model.
    
       Not all of the attributes are mandatory for
       implementations. Specifications describing implementations
       of the information model in this framework need to be
       explicit about which are mandatory and which are optional
       to implement
    
       The formal definitions of the classes and attributes are
       specified in Section 7.
    
    6.2. Energy Object (Class)
    
       An Energy Object (Class) represents a piece of equipment
       that is part of, or attached to, a communications network
       which is monitored, controlled, or aids in the management
       of another device for Energy Management.
    
       The Energy Object (Class) is an abstract class that
       contains the base attributes to represent a piece of
       equipment for Energy Management.  There are three types of
       Energy Object (Class): Device (Class), Component (Class)
       and Power Interface (Class).
    
    
    6.2.1. Device (Class)
    
       The Device (Class) is a sub-class of Energy Object (Class)
       that represents a physical piece of equipment.
    
       A Device (Class) instance represents a device that is a
       consumer, producer, meter, distributor, or store of energy.
    
       A Device (Class) instance may represent a physical device
       that contains other components.
    
    
    
    Claise, et al.        Expires October 28, 2014     [Page 14]
    

    Internet-Draft             EMAN Framework          April 2014
    
    6.2.2. Component (Class)
    
       The Component (Class) is a sub-class of Energy Object
       (Class) that represents a part of a physical piece of
       equipment.
    
    6.2.3. Power Interface (Class)
    
       A Power Interface (Class) represents the interconnections
       (inlet, outlet) among devices or components where energy
       can be provided, received, or both.
    
       The Power Interface (Class) is a sub-class of Energy Object
       (Class) that represents a physical inlet or outlet.
    
       There are some similarities between Power Interfaces and
       network interfaces.  A network interface can be set to
       different states, such as sending or receiving data on an
       attached line.  Similarly, a Power Interface can be
       receiving or providing energy.
    
       A Power Interface (Class) instance can represent
       (physically) an AC power socket, an AC power cord attached
       to a device, or an 8P8C (RJ45) PoE socket, etc.
    
    6.3. Energy Object Attributes
    
       This section describes categories of attributes for an
       Energy Object (Class).
    
    6.3.1. Identification
    
       A Universal Unique Identifier (UUID) [RFC4122] is used to
       uniquely and persistently identify an Energy Object.
    
       Every Energy Object has an optional unique human readable
       printable name.  Possible naming conventions are: textual
       DNS name, MAC address of the device, interface ifName, or a
       text string uniquely identifying the Energy Object.  As an
       example, in the case of IP phones, the Energy Object name
       can be the device's DNS name.
    
       Additionally an alternate key is provided to allow an
       Energy Object to be optionally linked with models in
       different systems.
    
    6.3.2. Context: General
    
    
    
    
    Claise, et al.        Expires October 28, 2014     [Page 15]
    

    Internet-Draft             EMAN Framework          April 2014
    
       In order to aid in reporting and in differentiation between
       Energy Objects, each object optionally contains information
       establishing its business, site, or organizational context
       within a deployment.
    
       The Energy Object (Class) contains a category attribute
       that broadly describes how an instance is used in a
       deployment. The category indicates if the Energy Object is
       primarily functioning as a consumer, producer, meter,
       distributor or store of energy.
    
       Given the category and context of an object, an EnMS can
       summarize or analyze measurements for the site.
    
    6.3.3. Context: Importance
    
       An Energy Object can provide an importance value in the
       range of 1 to 100 to help rank a device's use or relative
       value to the site.  The importance range is from 1 (least
       important) to 100 (most important).  The default importance
       value is 1.
    
       For example: A typical office environment has several types
       of phones, which can be rated according to their business
       impact.  A public desk phone has a lower importance (for
       example, 10) than a business-critical emergency phone (for
       example, 100).  As another example: A company can consider
       that a PC and a phone for a customer-service engineer are
       more important than a PC and a phone for lobby use.
    
       Although EnMS and administrators can establish their own
       ranking, the following example is a broad recommendation
       for commercial deployments [CISCO-EW]:
    
          90 to 100 Emergency response
          80 to 90 Executive or business-critical
          70 to 79 General or Average
          60 to 69 Staff or support
          40 to 59 Public or guest
          1  to 39 Decorative or hospitality
    
    6.3.4. Context: Keywords
    
       The Energy Object (Class) contains an attribute with
       context keywords.
    
       An Energy Object can provide a set of keywords that are a
       list of tags that can be used for grouping, for summary
       reporting (within or between Energy Management Domains),
    
    
    Claise, et al.        Expires October 28, 2014     [Page 16]
    

    Internet-Draft             EMAN Framework          April 2014
    
       and for searching. Potential examples are: IT, lobby,
       HumanResources, Accounting, StoreRoom, CustomerSpace,
       router, phone, floor2, or SoftwareLab.
    
       The specifics of how this tag is represented are left to
       the MIB module or other object definition documents to be
       based on this framework.
    
       There is no default value for a keyword. Multiple keywords
       can be assigned to an Energy Object.
    
    6.3.5. Context: Role
    
       The Energy Object (Class) contains a role attribute. The
       "role description" string indicates the primary purpose the
       Energy Object serves in the deployment.  This could be a
       string representing the purpose the Energy Object fulfills
       in the deployment.
    
       The specifics of how this tag is represented are left to
       the MIB module or other object definition documents to be
       based on this framework.
    
       Administrators can define any naming scheme for the role.
       As guidance, a two-word role that combines the service the
       Energy Object provides along with type can be used
       [IPENERGY].
    
       Example types of devices: Router, Switch, Light, Phone,
       WorkStation, Server, Display, Kiosk, HVAC.
    
       Example Services by Line of Business:
    
         Line of Business   Service
          -----------------------------------------------------
         Education           Student, Faculty,
       Administration,
                               Athletic
         Finance         Trader, Teller, Fulfillment
         Manufacturing     Assembly, Control, Shipping
         Retail          Advertising, Cashier
         Support         Helpdesk, Management
         Medical         Patient, Administration, Billing
    
       Role as a two-word string: "Faculty Desktop", "Teller
       Phone", "Shipping HVAC", "Advertising Display", "Helpdesk
       Kiosk", "Administration Switch".
    
    
    
    
    Claise, et al.        Expires October 28, 2014     [Page 17]
    

    Internet-Draft             EMAN Framework          April 2014
    
       The specifics of how this tag is represented are left to
       the MIB module or other object definition documents to be
       based on this framework.
    
    
    
    6.3.6. Context: Domain
    
       The Energy Object (Class) contains a string attribute to
       indicate membership in an Energy Management Domain. An
       Energy Management Domain can be any collection of Energy
       Objects in a deployment, but it is recommended to map 1:1
       with a metered or sub-metered portion of the site.
    
       In building management, a meter refers to the meter
       provided by the utility used for billing and measuring
       power to an entire building or unit within a building.  A
       sub-meter refers to a customer- or user-installed meter
       that is not used by the utility to bill but is instead used
       to get measurements from sub portions of a building.
    
       The specifics of how this tag is represented are left to
       the MIB module or other object definition documents to be
       based on this framework.
    
       An Energy Object MUST be a member of a single Energy
       Management Domain therefore one attribute is provided.
    
    6.4. Measurements
    
       The Energy Object (Class) contains attributes to describe
       power, energy and demand measurements.
    
       An analogy for understanding power versus energy
       measurements can be made to speed and distance in
       automobiles. Just as a speedometer indicates the rate of
       change of distance (speed), a power measurement indicates
       the rate of transfer of energy. The odometer in an
       automobile measures the cumulative distance traveled and
       similarly an energy measurement indicates the accumulated
       energy transferred.
    
       Demand measurements are averages of power measurements over
       time. So using the same analogy to an automobile: measuring
       the average vehicle speed over multiple intervals of time
       for a given distance travelled, demand is the average power
       measured over multiple time intervals for a given energy
       value.
    
    
    
    Claise, et al.        Expires October 28, 2014     [Page 18]
    

    Internet-Draft             EMAN Framework          April 2014
    
       Within this framework, energy will only be quantified in
       units of watt-hours. Physical devices measuring energy in
       other units must convert values to watt-hours or be
       represented by Energy Objects that convert to watt-hours.
    
    6.4.1. Measurements: Power
    
       The Energy Object (Class) contains a Nameplate Power
       attribute that describes the nominal power as specified by
       the manufacturer of the device. The EnMS can use the
       Nameplate Power for provisioning, capacity planning and
       (potentially) billing.
    
       The Energy Object (Class) has attributes that describe the
       present power information, along with how that measurement
       was obtained or derived (e.g., actual, estimated, or
       static).
    
       A power measurement is qualified with the units, magnitude
       and direction of power flow, and is qualified as to the
       means by which the measurement was made.
    
       Power measurement magnitude conforms to the [IEC61850]
       definition of unit multiplier for the SI (System
       International) units of measure.  Measured values are
       represented in SI units obtained by BaseValue * (10 ^
       Scale).  For example, if current power usage of an Energy
       Object is 17, it could be 17 W, 17 mW, 17 kW, or 17 mW,
       depending on the value of the scaling factor.  17 W implies
       that the BaseValue is 17 and Scale = 0, whereas 17 mW
       implies BaseValue = 17 and ScaleFactor = -3.
    
       An Energy Object (Class) indicates how the power
       measurement was obtained with a caliber and accuracy
       attribute that indicates:
          o Whether the measurements were made at the device
             itself or at a remote source.
          o Description of the method that was used to measure
             the power and whether this method can distinguish
             actual or estimated values.
          o Accuracy for actual measured values
    
    6.4.2. Measurements: Power Attributes
    
       The Energy Object (Class) contains an optional attribute
       that describes Power Attribute information reflecting the
       electrical characteristics of the measurement. These Power
       Attributes adhere to the [IEC61850-7-2] standard for
       describing AC measurements.
    
    
    Claise, et al.        Expires October 28, 2014     [Page 19]
    

    Internet-Draft             EMAN Framework          April 2014
    
    
    6.4.3. Measurements: Energy
    
       The Energy Object (Class) contains optional attributes that
       represent the energy used, received, produced and or
       stored.  Typically only devices or components that can
       measure actual power will have the ability to measure
       energy.
    
    6.4.4. Measurements: Demand
    
       The Energy Object (Class) contains optional attributes that
       represent demand information over time. Typically only
       devices or components that can report actual power are
       capable of measuring demand.
    
    
    6.5. Control
    
       The Energy Object (Class) contains a Power State Set
       (Class) attribute that represents the set of Power States a
       device or component supports.
    
       A Power State describes a condition or mode of a device or
       component. While Power States are typically used for
       control they may be used for monitoring only.
    
       A device or component is expected to support at least one
       set of Power States consisting of at least two states, an
       on state and an off state.
    
       There are many existing standards describing device and
       component Power States.  The framework supports modeling a
       mixed set of Power States defined in different standards. A
       basic example is given by the three Power States defined in
       IEEE1621 [IEEE1621]: on, off, and sleep. The DMTF [DMTF],
       ACPI [ACPI], and Printer Working Group (PWG) all define
       larger numbers of Power States.
    
       The semantics of a Power State are specified by
          a) the functionality provided by an Energy Object in
       this state,
          b) a limitation of the power that an Energy Object uses
       in this state,
          c) a combination of a) and b)
    
       The semantics of a Power State should be clearly defined.
       Limitation (curtailment) of the power used by an Energy
       Object in a state may be specified by:
    
    
    Claise, et al.        Expires October 28, 2014     [Page 20]
    

    Internet-Draft             EMAN Framework          April 2014
    
          o an absolute power value
          o a percentage value of power relative to the energy
             object's nameplate power
          o an indication of power relative to another power
             state. For example: Specify that power in state A is
             less than in state B.
          o For supporting Power State management an Energy
             Object provides statistics on Power States including
             the time an Energy Object spent in a certain Power
             State and the number of times an Energy Object
             entered a power state.
    
       When requesting an Energy Object to enter a Power State an
       indication of the Power State's name or number can be used.
       Optionally an absolute or percentage of Nameplate Power can
       be provided to allow the Energy Object to transition to a
       nearest or equivalent Power State.
    
       When an Energy Object is set to a particular Power State,
       the represented device or component may be busy. The Energy
       Object should set the desired Power State and then update
       the actual Power State when the device or component
       changes. There are then two Power State (Class) control
       attributes: actual and requested.
    
       The following sections describe well-known Power States for
       devices and components that should be modeled in the
       information model.
    
    6.5.1. Power State Sets
    
       There are several standards and implementations of Power
       State Sets.  The Energy Object (Class) support modeling one
       or multiple Power State Set implementation(s) on the device
       or component concurrently.
    
       There are currently three Power State Sets advocated:
         IEEE1621(256) - [IEEE1621]
         DMTF(512)     - [DMTF]
         EMAN(768)     - [this document]
    
       The respective specific states related to each Power State
       Set are specified in the following sections. The guidelines
       for the modification of Power State Sets are specified in
       the IANA Considerations Section.
    
    6.5.2. Power State Set: IEEE1621
    
    
    
    
    Claise, et al.        Expires October 28, 2014     [Page 21]
    

    Internet-Draft             EMAN Framework          April 2014
    
       The IEEE1621 Power State Set [IEEE1621] consists of 3
       rudimentary states: on, off or sleep.
    
       In IEEE1621 devices are limited to the three basic power
       states - on (2), sleep (1), and off (0). Any additional
       power states are variants of one of the basic states rather
       than a fourth state [IEEE1621].
    
    6.5.3. Power State Set: DMTF
    
       The DMTF [DMTF] standards organization has defined a power
       profile standard based on the CIM (Common Information
       Model) model that consists of 15 power states:
    
       {ON (2), SleepLight (3), SleepDeep (4), Off-Hard (5), Off-
       Soft (6), Hibernate(7), PowerCycle Off-Soft (8), PowerCycle
       Off-Hard (9), MasterBus reset (10), Diagnostic Interrupt
       (11), Off-Soft-Graceful (12), Off-Hard Graceful (13),
       MasterBus reset Graceful (14), Power-Cycle Off-Soft
       Graceful (15), PowerCycle-Hard Graceful (16)}
    
       The DMTF standard is targeted for hosts and computers.
       Details of the semantics of each Power State within the
       DMTF Power State Set can be obtained from the DMTF Power
       State Management Profile specification [DMTF].
    
       The DMTF power profile extends ACPI power states. The
       following table provides a mapping between DMTF and ACPI
       Power State Set:
    
            DMTF                              ACPI
           Reserved (0)
           Reserved (1)
           ON (2)                             G0-S0
           Sleep-Light (3)                    G1-S1 G1-S2
           Sleep-Deep (4)                     G1-S3
           Power Cycle (Off-Soft) (5)         G2-S5
           Off-hard (6)                       G3
           Hibernate (Off-Soft) (7)           G1-S4
           Off-Soft (8)                       G2-S5
           Power Cycle (Off-Hard) (9)         G3
           Master Bus Reset (10)              G2-S5
           Diagnostic Interrupt (11)          G2-S5
           Off-Soft Graceful (12)             G2-S5
           Off-Hard Graceful (13)             G3
           MasterBus Reset Graceful (14)      G2-S5
           Power Cycle off-soft Graceful (15) G2-S5
           Power Cycle off-hard Graceful (16) G3
    
    
    
    Claise, et al.        Expires October 28, 2014     [Page 22]
    

    Internet-Draft             EMAN Framework          April 2014
    
    6.5.4. Power State Set: IETF EMAN
    
       The EMAN Power States are an expansion of the basic Power
       States as defined in [IEEE1621] that also incorporates the
       Power States defined in [ACPI] and [DMTF].  Therefore, in
       addition to the non-operational states as defined in [ACPI]
       and [DMTF] standards, several intermediate operational
       states have been defined.
    
       Physical devices and components are expected to support the
       EMAN Power State Set or to be modeled via an Energy Object
       the supports these states.
    
       An Energy Object may implement fewer or more Power States
       than a particular EMAN Power State Set specifies. In that
       case, the Energy Object implementation can determine its
       own mapping to the predefined EMAN Power States within the
       EMAN Power State Set.
    
       There are twelve EMAN Power States that expand on
       [IEEE1621]. The expanded list of Power States is derived
       from [CISCO-EW] and is divided into six operational states
       and six non-operational states.
    
       The lowest non-operational state is 1 and the highest is 6.
       Each non-operational state corresponds to an [ACPI] Global
       and System state between G3 (hard-off) and G1 (sleeping).
       Each operational state represents a performance state, and
       may be mapped to [ACPI] states P0 (maximum performance
       power) through P5 (minimum performance and minimum power).
    
       In each of the non-operational states (from mechoff(0) to
       ready(5)), the Power State preceding it is expected to have
       a lower Power value and a longer delay in returning to an
       operational state:
    
                mechoff(0) : An off state where no Energy Object
       features are available.  The Energy Object is unavailable.
       No energy is being consumed and the power connector can be
       removed.
    
                softoff(1) : Similar to mechoff(0), but some
       components remain powered or receive trace power so that
       the Energy Object can be awakened from its off state.  In
       softoff(1), no context is saved and the device typically
       requires a complete boot when awakened.
    
             hibernate(2): No Energy Object features are
       available.   The Energy Object may be awakened without
    
    
    Claise, et al.        Expires October 28, 2014     [Page 23]
    

    Internet-Draft             EMAN Framework          April 2014
    
       requiring a complete boot, but the time for availability is
       longer than sleep(3). An example for state hibernate(2) is
       a save to-disk state where DRAM context is not maintained.
       Typically, energy consumption is zero or close to zero.
    
                sleep(3)    : No Energy Object features are
       available, except for out-of-band management, such as wake-
       up mechanisms.  The time for availability is longer than
       standby(4). An example for state sleep(3) is a save-to-RAM
       state, where DRAM context is maintained.  Typically, energy
       consumption is close to zero.
    
                standby(4) : No Energy Object features are
       available, except for out-of-band management, such as wake-
       up mechanisms.  This mode is analogous to cold-standby.
       The time for availability is longer than ready(5).  For
       example processor context is may not be maintained.
       Typically, energy consumption is close to zero.
    
                ready(5)    : No Energy Object features are
       available, except for out-of-band management, such as wake-
       up mechanisms. This mode is analogous to hot-standby.  The
       Energy Object can be quickly transitioned into an
       operational state.  For example, processors are not
       executing, but processor context is maintained.
    
                lowMinus(6) : Indicates some Energy Object
       features may not be available and the Energy Object has
       taken measures or selected options to use less energy than
       low(7).
    
                low(7)      : Indicates some features may not be
       available and the Energy Object has taken measures or
       selected options to use less energy than mediumMinus(8).
    
                mediumMinus(8): Indicates all Energy Object
       features are available but the Energy Object has taken
       measures or selected options to use less energy than
       medium(9).
    
                medium(9)  : Indicates all Energy Object features
       are available but the Energy Object has taken measures or
       selected options to use less energy than highMinus(10).
    
                highMinus(10): Indicates all Energy Object
       features are available and has taken measures or selected
       options to use less energy than high(11).
    
    
    
    
    Claise, et al.        Expires October 28, 2014     [Page 24]
    

    Internet-Draft             EMAN Framework          April 2014
    
                high(11)    : Indicates all Energy Object features
       are available and the Energy Object may use the maximum
       energy as indicated by the Nameplate Power.
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    Claise, et al.        Expires October 28, 2014     [Page 25]
    

    Internet-Draft             EMAN Framework          April 2014
    
    
    6.5.5. Power State Sets Comparison
    
       A comparison of Power States from different Power State
       Sets can be seen in the following table:
         IEEE1621  DMTF         ACPI           EMAN
    
         Non-operational states
         off       Off-Hard     G3, S5         mechoff(0)
         off       Off-Soft     G2, S5         softoff(1)
         off       Hibernate    G1, S4         hibernate(2)
         sleep     Sleep-Deep   G1, S3         sleep(3)
         sleep     Sleep-Light  G1, S2         standby(4)
         sleep     Sleep-Light  G1, S1         ready(5)
    
         Operational states:
         on        on           G0, S0, P5     lowMinus(6)
         on        on           G0, S0, P4     low(7)
         on        on           G0, S0, P3     mediumMinus(8)
         on        on           G0, S0, P2     medium(9)
         on        on           G0, S0, P1     highMinus(10)
         on        on           G0, S0, P0     high(11)
    
    6.6. Relationships
    
       The Energy Object (Class) contains a set of Relationship
       (Class) attributes to model the relationships between
       devices and components.  Two Energy Objects can establish
       an Energy Object Relationship to model the deployment
       topology with respect to Energy Management.
    
       Relationships are modeled with a Relationship (Class) that
       contains the UUID of the other participant in the
       relationship and a name that describes the type of
       relationship [CHEN]. The types of relationships are:  Power
       Source, Metering, and Aggregations.
    
          o A Power Source Relationship is relationship where one
             Energy Object provides power to one or more Energy
             Objects. The Power Source Relationship gives a view
             of the physical wiring topology.  For example: a data
             center server receiving power from two specific Power
             Interfaces from two different PDUs.
    
             Note: A Power Source Relationship may or may not
             change as the direction of power changes between two
             Energy Objects. The relationship may remain to
             indicate the change of power direction was unintended
             or an error condition.
    
    
    Claise, et al.        Expires October 28, 2014     [Page 26]
    

    Internet-Draft             EMAN Framework          April 2014
    
    
          o A Metering Relationship is relationship where one
             Energy Object measures power, energy, demand or Power
             Attributes of one or more other Energy Objects. The
             Metering Relationship gives the view of the metering
             topology.  Physical meters can be placed anywhere in
             a power distribution tree.  For example, utility
             meters monitor and report accumulated power
             consumption of the entire building. Logically, the
             metering topology overlaps with the wiring topology,
             as meters are connected to the wiring topology.  A
             typical example is meters that clamp onto the
             existing wiring.
    
          o An Aggregation Relationship is a relationship where
             one Energy Object aggregates Energy Management
             information of one or more other Energy Objects. The
             Aggregation Relationship gives a model of devices
             that may aggregate (sum, average, etc) values for
             other devices.  The Aggregation Relationship is
             slightly different compared to the other
             relationships as this refers more to a management
             function.
    
       In some situations, it is not possible to discover the
       Energy Object relationships, and an EnMS or administrator
       must set them.  Given that relationships can be assigned
       manually, the following sections describe guidelines for
       use.
    
    
    6.6.1. Relationship Conventions and Guidelines
    
       This Energy Management framework does not impose many
       "MUST" rules related to Energy Object Relationships. There
       are always corner cases that could be excluded with too
       strict specifications of relationships. However, the
       framework proposes a series of guidelines, indicated with
       "SHOULD" and "MAY".
    
    6.6.2. Guidelines: Power Source
    
       Power Source relationships are intended to identify the
       connections between Power Interfaces. This is analogous to
       a Layer 2 connection in networking devices (a "one-hop
       connection").
    
       The preferred modeling would be for Power Interfaces to
       participate in Power Source Relationships. It some cases
    
    
    Claise, et al.        Expires October 28, 2014     [Page 27]
    

    Internet-Draft             EMAN Framework          April 2014
    
       Energy Objects may not have the capability to model Power
       Interfaces.  Therefore a Power Source Relationship can be
       established between two Energy Objects or two non-connected
       Power Interfaces.
    
       While strictly speaking Components and Power Interfaces on
       the same Device do provide or receive energy from each
       other, the Power Source relationship is intended to show
       energy transfer between Devices. Therefore the relationship
       is implied when on the same Device.
    
       An Energy Object SHOULD NOT establish a Power Source
       Relationship with a Component.
          o A Power Source Relationship SHOULD be established
             with the next known Power Interface in the wiring
             topology.
    
          o The next known Power Interface in the wiring topology
             would be the next device implementing the framework.
             In some cases the domain of devices under management
             may include some devices that do not implement the
             framework. In these cases, the Power Source
             relationship can be established with the next device
             in the topology that implements the framework and
             logically shows the Power Source of the device.
    
          o Transitive Power Source relationships SHOULD NOT be
             established.  For example, if an Energy Object A has
             a Power Source Relationship "Poweredby" with the
             Energy Object B, and if the Energy Object B has a
             Power Source Relationship "Poweredby" with the Energy
             Object C, then the Energy Object A SHOULD NOT have a
             Power Source Relationship "Poweredby" with the Energy
             Object C.
    
    6.6.3. Guidelines: Metering Relationship
    
       Metering Relationships are intended to show when one device
       acting as a meter is measuring the power or energy at a
       point in a power distribution system. Since one point of a
       power distribution system may cover many devices within a
       wiring topology, this relationship type can be seen as a
       set.
    
       Some devices, however, may include measuring hardware for
       components, and outlets or for the entire device. For
       example, some PDUs may have the ability to measure power
       for each outlet and are commonly referred to as metered-by-
       outlet. Others may be able to control power at each power
    
    
    Claise, et al.        Expires October 28, 2014     [Page 28]
    

    Internet-Draft             EMAN Framework          April 2014
    
       outlet but can only measure power at the power inlet -
       commonly referred to as metered-by-device.
    
       While the Metering Relationship could be used to represent
       a device as metered-by-outlet or metered-by-device, the
       Metering Relationship SHOULD be used to model the
       relationship between a meter and all devices covered by the
       meter downstream in the power distribution system
    
       In general:
          o A Metering Relationship MAY be established with any
             other Energy Object, Component, or Power Interface.
    
          o Transitive Metering Relationships MAY be used.
    
          o When there is a series of meters for one Energy
             Object, the Energy Object MAY establish a Metering
             relationship with one or more of the meters.
    
    6.6.4. Guidelines: Aggregation
    
       Aggregation relationships are intended to identify when one
       device is used to accumulate values from other devices.
       Typically this is for energy or power values among devices
       and not for Components or Power Interfaces on the same
       device.
    
       The intent of Aggregation relationships is to indicate when
       one device is providing aggregate values for a set of other
       devices when it is not obvious from the power source or
       simple containment within a device.
    
       Establishing aggregation relationships within the same
       device would make modeling more complex and the aggregated
       values can be implied from the use of Power Inlets, outlet
       and Energy Object values on the same device.
    
       Since an EnMS is naturally a point of aggregation it is not
       necessary to model aggregation for Energy Management
       Systems.
    
       The Aggregation Relationship is intended for power and
       energy. It MAY be used for aggregation of other values from
       the information model, but the rules and logical ability to
       aggregate each attribute is out of scope for this document.
    
       In general:
    
    
    
    
    Claise, et al.        Expires October 28, 2014     [Page 29]
    

    Internet-Draft             EMAN Framework          April 2014
    
          o A Device SHOULD NOT establish an Aggregation
             Relationship with Components contained on the same
             device.
          o A Device SHOULD NOT establish an Aggregation
             Relationship with the Power Interfaces contained on
             the same device.
          o A Device SHOULD NOT establish an Aggregation
             Relationship with an EnMS.
          o Aggregators SHOULD log or provide notification in the
             case of errors or missing values while performing
             aggregation.
    
    6.6.5. Energy Object Relationship Extensions
    
       This framework for Energy Management is based on three
       relationship types: Aggregation , Metering, and Power
       Source.
       This framework is defined with possible future extension of
       new Energy Object Relationships in mind.
       For example:
          o Some Devices that may not be IP connected. This can
             be modeled with a proxy relationship to an Energy
             Object within the domain. This type of proxy
             relationship is left for further development.
          o A Power Distribution Unit (PDU) that allows devices
             and components like outlets to be "ganged" together
             as a logical entity for simplified management
             purposes, could be modeled with an extension called a
             "gang relationship", whose semantics would specify
             the Energy Objects' grouping.
    
    7. Energy Management Information Model
    
       This section presents an information model expression of
       the concepts in this framework as a reference for
       implementers. The information model is implemented as MIB
       modules in the different related IETF EMAN documents.
       However, other programming structures with different data
       models could be used as well.
    
       Data modeling specifications of this information model may
       where needed specify which attributes are required or
       optional.
    
      Syntax
    
         UML Construct
         [ISO-IEC-19501-2005] Equivalent Notation
         -------------------- ------------------------------------
    
    
    Claise, et al.        Expires October 28, 2014     [Page 30]
    

    Internet-Draft             EMAN Framework          April 2014
    
         Notes                // Notes
         Class
         (Generalization)     CLASS name {member..}
         Sub-Class
         (Specialization)     CLASS subclass
                                    EXTENDS superclass {member..}
         Class Member
         (Attribute)          attribute : type
    
      Model
    
       CLASS EnergyObject {
    
             // identification / classification
             index        : int
             identifier   : uuid
             alternatekey : string
    
             // context
             domainName      : string
             role            : string
             keywords [0..n] : string
             importance      : int
    
             // relationship
             relationships [0..n] : Relationship
    
             // measurements
             nameplate    : Nameplate
             power        : PowerMeasurement
             energy       : EnergyMeasurment
             demand       : DemandMeasurement
    
             // control
             powerControl [0..n] : PowerStateSet
       }
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    Claise, et al.        Expires October 28, 2014     [Page 31]
    

    Internet-Draft             EMAN Framework          April 2014
    
       CLASS PowerInterface EXTENDS EnergyObject{
             eoIfType : enum { inlet, outlet, both}
       }
    
       CLASS Device EXTENDS EnergyObject {
             eocategory   : enum { producer, consumer, meter,
       distributor, store }
             powerInterfaces[0..n]: PowerInterface
             components [0..n]    : Component
       }
    
       CLASS Component EXTENDS EnergyObject
             eocategory   : enum { producer, consumer, meter,
       distributor, store }
             powerInterfaces[0..n]: PowerInterface
             components [0..n]    : Component
    
       }
    
       CLASS Nameplate {
             nominalPower : PowerMeasurement
             details      : URI
       }
    
       CLASS Relationship {
             relationshipType    : enum { meters, meteredby,
       powers, poweredby, aggregates, aggregatedby }
             relationshipObject  : uuid
       }
    
       CLASS Measurement {
             multiplier: enum { -24..24}
             caliber   : enum { actual, estimated, static }
             accuracy  : enum { 0..10000} // hundreds of percent
       }
    
       CLASS PowerMeasurement EXTENDS Measurement {
             value          : long
             units          : "W"
             powerAttribute : PowerAttribute
       }
    
       CLASS EnergyMeasurement EXTENDS Measurement {
             startTime : time
             units     : "kWh"
             provided  : long
             used      : long
             produced  : long
             stored    : long
    
    
    Claise, et al.        Expires October 28, 2014     [Page 32]
    

    Internet-Draft             EMAN Framework          April 2014
    
       }
    
       CLASS TimedMeasurement EXTENDS Measurement {
             startTime  : timestamp
             value      : Measurement
             maximum    : Measurement
       }
    
       CLASS TimeInterval {
             value      : long
             units      : enum { seconds, miliseconds,...}
       }
    
       CLASS DemandMeasurement EXTENDS Measurement {
             intervalLength : TimeInterval
             intervals      : long
             intervalMode   : enum { periodic, sliding, total }
             intervalWindow : TimeInterval
             sampleRate     : TimeInterval
             status         : enum { active, inactive }
             measurements[0..n] : TimedMeasurements
       }
    
       CLASS PowerStateSet {
             powerSetIdentifier : int
             name               : string
             powerStates [0..n] : PowerState
             operState          : int
             adminState         : int
             reason             : string
             configuredTime     : timestamp
       }
    
       CLASS PowerState {
             powerStateIdentifier  : int
             name             : string
             cardinality      : int
             maximumPower     : PowerMeasurement
             totalTimeInState : time
             entryCount       : long
       }
    
       CLASS PowerAttribute {
             acQuality  : ACQuality
       }
    
       CLASS ACQuality {
             acConfiguration : enum {SNGL, DEL,WYE}
             avgVoltage         : long
    
    
    Claise, et al.        Expires October 28, 2014     [Page 33]
    

    Internet-Draft             EMAN Framework          April 2014
    
             avgCurrent         : long
             frequency          : long
             unitMultiplier     : int
             accuracy           : int
             totalActivePower   : long
             totalReactivePower : long
             totalApparentPower : long
             totalPowerFactor   : long
             phases [0..2]      : ACPhase
       }
    
       CLASS ACPhase {
             phaseIndex    : long
             avgCurrent    : long
             activePower   : long
             reactivePower : long
             apparentPower : long
             powerFactor   : long
       }
    
       CLASS DelPhase EXTENDS ACPhase {
             phaseToNextPhaseVoltage  : long
             thdVoltage : long
             thdCurrent : long
       }
    
       CLASS WYEPhase EXTENDS ACPhase {
             phaseToNeutralVoltage : long
             thdCurrent : long
             thdVoltage : long
       }
    
    8. Modeling Relationships between Devices
    
       In this section we give examples of how to use the EMAN
       information model to model physical topologies.  Where
       applicable, we show how the framework can be applied when
       devices can be modeled with Power Interfaces.  We also show
       how the framework can be applied when devices cannot be
       modeled with Power Interfaces but only monitored or control
       as a whole. For instance, a PDU may only be able to measure
       power and energy for the entire unit without the ability to
       distinguish among the inlets or outlets.
    
    8.1. Power Source Relationship
    
       The Power Source relationship is used to model the
       interconnections between devices, components and/Power
       Interfaces to indicate the source of energy for a device.
    
    
    Claise, et al.        Expires October 28, 2014     [Page 34]
    

    Internet-Draft             EMAN Framework          April 2014
    
       In the following examples we show variations on modeling
       the reference topologies using relationships.
    
       Given for all cases:
    
       Device W: A computer with one power supply. Power Interface
       1 is an inlet for Device W.
    
       Device X: A computer with two power supplies. Power
       Interface 1 and power interface 2 are both inlets for
       Device X.
    
       Device Y: A PDU with multiple Power Interfaces numbered
       0..10. Power Interface 0 is an inlet and Power Interface
       1..10 are outlets.
    
       Device Z: A PDU with multiple Power Interfaces numbered
       0..10. Power Interface 0 is an inlet and Power Interface
       1..10 are outlets.
    
      Case 1: Simple Device with one Source
    
       Physical Topology:
    
          o Device W inlet 1 is plugged into Device Y outlet 8.
    
       With Power Interfaces:
    
          o Device W has an Energy Object representing the
             computer itself as well as one Power Interface
             defined as an inlet.
          o Device Y would have an Energy Object representing the
             PDU itself (the Device), with a Power Interface 0
             defined as an inlet and Power Interfaces 1..10
             defined as outlets.
    
       The interfaces of the devices would have a Power Source
       Relationship such that:
       Device W inlet 1 is powered by Device Y outlet 8.
    
          +-------+------+       poweredBy +------+----------+
          | PDU Y | PI 8 |-----------------| PI 1 | Device W |
          +-------+------+ powers          +------+----------+
    
       Without Power Interfaces:
    
          o Device W has an Energy Object representing the
             computer.
    
    
    Claise, et al.        Expires October 28, 2014     [Page 35]
    

    Internet-Draft             EMAN Framework          April 2014
    
          o Device Y would have an Energy Object representing the
             PDU.
    
       The devices would have a Power Source Relationship such
       that:
       Device W is powered by Device Y.
    
    
          +----------+       poweredBy +------------+
          |  PDU Y   |-----------------|  Device W  |
          +----------+ powers          +------------+
    
      Case 2: Multiple Inlets
    
       Physical Topology:
          o Device X inlet 1 is plugged into Device Y outlet 8.
          o Device X inlet 2 is plugged into Device Y outlet 9.
    
       With Power Interfaces:
    
          o Device X has an Energy Object representing the
             computer itself. It contains two Power Interfaces
             defined as inlets.
          o Device Y would have an Energy Object representing the
             PDU itself (the Device), with a Power Interface 0
             defined as an inlet and Power Interfaces 1..10
             defined as outlets.
    
       The interfaces of the devices would have a Power Source
       Relationship such that:
       Device X inlet 1 is powered by Device Y outlet 8.
       Device X inlet 2 is powered by Device Y outlet 9.
    
          +-------+------+        poweredBy+------+----------+
          |       | PI 8 |-----------------| PI 1 |          |
          |       |      |powers           |      |          |
          | PDU Y +------+        poweredBy+------+ Device X |
          |       | PI 9 |-----------------| PI 2 |          |
          |       |      |powers           |      |          |
          +-------+------+                 +------+----------+
    
       Without Power Interfaces:
    
          o Device X has an Energy Object representing the
             computer. Device Y has an Energy Object representing
             the PDU.
    
    
    
    
    Claise, et al.        Expires October 28, 2014     [Page 36]
    

    Internet-Draft             EMAN Framework          April 2014
    
    
       The devices would have a Power Source Relationship such
       that:
       Device X is powered by Device Y.
    
          +----------+       poweredBy +------------+
          |  PDU Y   |-----------------|  Device X  |
          +----------+ powers          +------------+
    
      Case 3: Multiple Sources
    
       Physical Topology:
          o Device X inlet 1 is plugged into Device Y outlet 8.
          o Device X inlet 2 is plugged into Device Z outlet 9.
    
       With Power Interfaces:
    
          o Device X has an Energy Object representing the
             computer itself. It contains two Power Interface
             defined as inlets.
          o Device Y would have an Energy Object representing the
             PDU itself  (the Device), with a Power Interface 0
             defined as an inlet and Power Interfaces 1..10
             defined as outlets.
          o Device Z would have an Energy Object representing the
             PDU itself  (the Device), with a Power Interface 0
             defined as an inlet and Power Interfaces 1..10
             defined as outlets.
    
       The interfaces of the devices would have a Power Source
       Relationship such that:
       Device X inlet 1 is powered by Device Y outlet 8.
       Device X inlet 2 is powered by Device Z outlet 9.
    
          +-------+------+        poweredBy+------+----------+
          | PDU Y | PI 8 |-----------------| PI 1 |          |
          |       |      |powers           |      |          |
          +-------+------+                 +------+          |
                                                  | Device X |
          +-------+------+        poweredBy+------+          |
          | PDU Z | PI 9 |-----------------| PI 2 |          |
          |       |      |powers           |      |          |
          +-------+------+                 +------+----------+
    
       Without Power Interfaces:
    
    
    
    
    Claise, et al.        Expires October 28, 2014     [Page 37]
    

    Internet-Draft             EMAN Framework          April 2014
    
          o Device X has an Energy Object representing the
             computer. Device Y and Z would both have respective
             Energy Objects representing each entire PDU.
    
       The devices would have a Power Source Relationship such
       that:
       Device X is powered by Device Y and powered by Device Z.
    
          +----------+           poweredBy +------------+
          |  PDU Y   |---------------------|  Device X  |
          +----------+ powers              +------------+
    
          +----------+           poweredBy +------------+
          |  PDU Z   |---------------------|  Device X  |
          +----------+ powers              +------------+
    
    8.2. Metering Relationship
    
       A meter in a power distribution system can logically
       measure the power or energy for all devices downstream from
       the meter in the power distribution system.  As such, a
       Metering relationship can be seen as a relationship between
       a meter and all of the devices downstream from the meter.
    
       We define in this case a Metering relationship between a
       meter and devices downstream from the meter.
    
       +-----+---+    meteredBy +--------+   poweredBy +-------+
       |Meter| PI|--------------| switch |-------------| phone |
       +-----+---+ meters       +--------+ powers      +-------+
               |                                           |
               |                                 meteredBy |
               +-------------------------------------------+
                meters
    
       In cases where the Power Source topology cannot be
       discovered or derived from the information available in the
       Energy Management Domain, the metering topology can be used
       to relate the upstream meter to the downstream devices in
       the absence of specific Power Source relationships.
    
       A Metering Relationship can occur between devices that are
       not directly connected, as shown in the following figure:
    
                          +---------------+
                          |   Device 1    |
                          +---------------+
                          |      PI       |
    
    
    Claise, et al.        Expires October 28, 2014     [Page 38]
    

    Internet-Draft             EMAN Framework          April 2014
    
                          +---------------+
                                  |
                          +---------------+
                          |     Meter     |
                          +---------------+
                                  .
                                  .
                                  .
                 meters        meters           meters
           +----------+   +----------+   +-----------+
           | Device A |   | Device B |   | Device C  |
           +----------+   +----------+   +-----------+
    
       An analogy to communications networks would be modeling
       connections between servers (meters) and clients (devices)
       when the complete Layer 2 topology between the servers and
       clients is not known.
    
    8.3. Aggregation Relationship
    
       Some devices can act as aggregation points for other
       devices.  For example, a PDU controller device may contain
       the summation of power and energy readings for many PDU
       devices.  The PDU controller will have aggregate values for
       power and energy for a group of PDU devices.
    
       This aggregation is independent of the physical power or
       communication topology.
    
       The functions that the aggregation point may perform
       include the calculation of values such as average, count,
       maximum, median, minimum, or the listing (collection) of
       the aggregation values, etc.
       Based on the experience gained on aggregations at the IETF
       [RFC7015], the aggregation function in the EMAN framework
       is limited to the summation.
    
       When aggregation occurs across a set of entities, values to
       be aggregated may be missing for some entities.  The EMAN
       framework does not specify how these should be treated, as
       different implementations may have good reason to take
       different approaches.  One common treatment is to define
       the aggregation as missing if any of the constituent
       elements are missing (useful to be most precise). Another
       is to treat the missing value as zero (useful to have
       continuous data streams).
    
    
    
    
    
    Claise, et al.        Expires October 28, 2014     [Page 39]
    

    Internet-Draft             EMAN Framework          April 2014
    
       The specifications of aggregation functions are out of
       scope of the EMAN framework, but must be clearly specified
       by the equipment vendor.
    
    9. Relationship to Other Standards
    
       This Energy Management framework uses, as much as possible,
       existing standards especially with respect to information
       modeling and data modeling [RFC3444].
    
       The data model for power- and energy-related objects is
       based on [IEC61850].
    
       Specific examples include:
          o The scaling factor, which represents Energy Object
             usage magnitude, conforms to the [IEC61850]
             definition of unit multiplier for the SI (System
             International) units of measure.
          o The electrical characteristic is based on the ANSI
             and IEC Standards, which require that we use an
             accuracy class for power measurement.  ANSI and IEC
             define the following accuracy classes for power
             measurement:
          o IEC 62053-22  60044-1 class 0.1, 0.2, 0.5, 1  3.
          o ANSI C12.20 class 0.2, 0.5
          o The electrical characteristics and quality adhere
             closely to the [IEC61850-7-4] standard for describing
             AC measurements.
          o The power state definitions are based on the DMTF
             Power State Profile and ACPI models, with operational
             state extensions.
    
    10. Implementation Status
    
       RFC Editor Note: Please remove this section and the
       reference to [RFC6982] before publication.
    
       This section records the status of known implementations of
       the protocol defined by this specification at the time of
       posting of this Internet-Draft, and is based on a proposal
       described in [RFC6982].  The description of implementations
       in this section is intended to assist the IETF in its
       decision processes in progressing drafts to RFCs.  Please
       note that the listing of any individual implementation here
       does not imply endorsement by the IETF.  Furthermore, no
       effort has been spent to verify the information presented
       here that was supplied by IETF contributors. This is not
       intended as, and must not be construed to be, a catalog of
    
    
    
    Claise, et al.        Expires October 28, 2014     [Page 40]
    

    Internet-Draft             EMAN Framework          April 2014
    
       available implementations or their features.  Readers are
       advised to note that other implementations may exist.
    
       According to RFC 6982, "this will allow reviewers and
       working groups to assign due consideration to documents
       that have the benefit of running code, which may serve as
       evidence of valuable experimentation and feedback that have
       made the implemented protocols more mature.
    
       Implementation descriptions for this document are
       maintained at:
       http://tools.ietf.org/wg/eman/trac/wiki/EmanImplementations
    
    11. Security Considerations
    
       Regarding the data attributes specified here, some or all
       may be considered sensitive or vulnerable in some network
       environments. Reading or writing these attributes without
       proper protection such as encryption or access
       authorization will have negative effects on network
       capabilities. Event logs for audit purposes on
       configuration and other changes should be generated
       according to current authorization, audit, and accounting
       principles to facilitate investigations (compromise or
       benign mis-configurations) or any reporting requirements.
    
       The information and control capabilities specified in this
       framework could be exploited with detriment to a site or
       deployment. Implementers of the framework SHOULD examine
       and mitigate security threats with respect to these new
       capabilities.
    
       [RFC3410] User Security Model for SNMPv3 presents a good
       description of threats and mitigations for the SNMPv3
       protocol that can be used as a guide for implementations of
       this framework using other protocols.
    
    11.1. Security Considerations for SNMP
    
       Readable objects in MIB modules (i.e., objects with a MAX-
       ACCESS other than not-accessible) may be considered
       sensitive or vulnerable in some network environments.  It
       is important to control GET and/or NOTIFY access to these
       objects and possibly to encrypt the values of these objects
       when sending them over the network via SNMP.
    
       The support for SET operations in a non-secure environment
       without proper protection can have a negative effect on
       network operations.
    
    
    Claise, et al.        Expires October 28, 2014     [Page 41]
    

    Internet-Draft             EMAN Framework          April 2014
    
    
       For example:
          o Unauthorized changes to the Energy Management Domain
             or business context of a device will result in
             misreporting or interruption of power.
          o Unauthorized changes to a power state will disrupt
             the power settings of the different devices, and
             therefore the state of functionality of the
             respective devices.
          o Unauthorized changes to the demand history will
             disrupt proper accounting of energy usage.
    
       With respect to data transport, SNMP versions prior to
       SNMPv3 did not include adequate security.  Even if the
       network itself is secure (for example, by using IPsec),
       there is still no secure control over who on the secure
       network is allowed to access and GET/SET
       (read/change/create/delete) the objects in these MIB
       modules.
    
       It is recommended that implementers consider the security
       features as provided by the SNMPv3 framework (see
       [RFC3410], section 8), including full support for the
       SNMPv3 cryptographic mechanisms (for authentication and
       confidentiality).
    
       Further, deployment of SNMP versions prior to SNMPv3 is not
       recommended.  Instead, it is recommended to deploy SNMPv3
       and to enable cryptographic security.  It is then a
       customer/operator responsibility to ensure that the SNMP
       entity giving access to an instance of these MIB modules is
       properly configured to give access to the objects only to
       those principals (users) that have legitimate rights to GET
       or SET (change/create/delete) them.
    
    
    12. IANA Considerations
    12.1. IANA Registration of new Power State Sets
    
       This document specifies an initial set of Power State Sets.
       The list of these Power State Sets with their numeric
       identifiers is given is Section 6. IANA maintains the lists
       of Power State Sets.
    
       New assignments for Power State Set are administered by
       IANA through Expert Review [RFC5226], i.e., review by one
       of a group of experts designated by an IETF Area Director.
       The group of experts must check the requested state for
       completeness and accuracy of the description. A pure vendor
    
    
    Claise, et al.        Expires October 28, 2014     [Page 42]
    

    Internet-Draft             EMAN Framework          April 2014
    
       specific implementation of Power State Set shall not be
       adopted; since it would lead to proliferation of Power
       State Sets.
    
       Power states in a Power State Set are limited to 255
       distinct values. New Power State Set must be assigned the
       next available numeric identifier that is a multiple of
       256.
    
    12.1.1. IANA Registration of the IEEE1621 Power State Set
    
       This document specifies a set of values for the IEEE1621
       Power State Set [IEEE1621].  The list of these values with
       their identifiers is given in Section 6.5.2.  IANA created
       a new registry for IEEE1621 Power State Set identifiers and
       filled it with the initial list of identifiers.
    
       New assignments (or potentially deprecation) for the
       IEEE1621 Power State Set is administered by IANA through
       Expert Review [RFC5226], i.e., review by one of a group of
       experts designated by an IETF Area Director.  The group of
       experts must check the requested state for completeness and
       accuracy of the description.
    
    12.1.2. IANA Registration of the DMTF Power State Set
    
       This document specifies a set of values for the DMTF Power
       State Set.  The list of these values with their identifiers
       is given in Section 6.5.3. IANA has created a new registry
       for DMTF Power State Set identifiers and filled it with the
       initial list of identifiers.
    
       New assignments (or potentially deprecation) for the DMTF
       Power State Set is administered by IANA through Expert
       Review [RFC5226], i.e., review by one of a group of experts
       designated by an IETF Area Director.  The group of experts
       must check the conformance with the DMTF standard [DMTF],
       on the top of checking for completeness and accuracy of the
       description.
    
    12.1.3. IANA Registration of the EMAN Power State Set
    
       This document specifies a set of values for the EMAN Power
       State Set.  The list of these values with their identifiers
       is given in Section 6.5.4.  IANA has created a new registry
       for EMAN Power State Set identifiers and filled it with the
       initial list of identifiers.
    
    
    
    
    Claise, et al.        Expires October 28, 2014     [Page 43]
    

    Internet-Draft             EMAN Framework          April 2014
    
       New assignments (or potentially deprecation) for the EMAN
       Power State Set is administered by IANA through Expert
       Review [RFC5226], i.e., review by one of a group of experts
       designated by an IETF Area Director.  The group of experts
       must check the requested state for completeness and
       accuracy of the description.
    
    
    12.2. Updating the Registration of Existing Power State Sets
    
       With the evolution of standards, over time, it may be
       important to deprecate some of the existing the Power State
       Sets, or to add or deprecate some Power States within a
       Power State Set.
    
       The registrant shall publish an Internet-draft or an
       individual submission with the clear specification on
       deprecation of Power State Sets or Power States registered
       with IANA.  The deprecation or addition shall be
       administered by IANA through Expert Review [RFC5226], i.e.,
       review by one of a group of experts designated by an IETF
       Area Director. The process should also allow for a
       mechanism for cases where others have significant
       objections to claims on deprecation of a registration.
    
    13. References
    
    Normative References
    
       [RFC2119]  Bradner, S., "Key words for use in RFCs to
                 Indicate Requirement Levels", BCP 14, RFC 2119,
                 March 1997
    
       [RFC3410]  Case, J., Mundy, R., Partain, D., and B.
                 Stewart, "Introduction and Applicability
                 Statements for Internet Standard Management
                 Framework ", RFC 3410, December 2002
    
       [RFC3444] Pras, A., Schoenwaelder, J. "On the Differences
                 between Information Models and Data Models", RFC
                 3444, January 2003
    
    
       [RFC4122] Leach, P., Mealling, M., and R. Salz," A
                 Universally Unique Identifier (UUID) URN
                 Namespace", RFC 4122, July 2005
    
    
    
    
    
    Claise, et al.        Expires October 28, 2014     [Page 44]
    

    Internet-Draft             EMAN Framework          April 2014
    
       [RFC5226] Narten, T., and H. Alvestrand, "Guidelines for
                 Writing an IANA Considerations Section in RFCs",
                 RFC 5226, May 2008
    
       [RFC6933]  Bierman, A. and K. McCloghrie, "Entity MIB
                 (Version4)", RFC 6933, May 2013
    
       [RFC6988]  Quittek, J., Chandramouli, M., Winter, R.,
                 Dietz, T., and B. Claise, "Requirements for
                 Energy Management", RFC 6988, Septembre 2013
    
    
       [ISO-IEC-19501-2005] ISO/IEC 19501:2005, Information
                 technology, Open Distributed Processing --
                 Unified Modeling Language (UML), January 2005
    
    Informative References
    
       [RFC3986] T. Berners-Lee, Ed., " Uniform Resource
                 Identifier (URI): Generic Syntax", RFC3 986,
                 January 2005
    
       [RFC6982] Y. Sheffer, and Adrian Farrel, "Improving
                 Awareness of Running Code: The Implementation
                 Status Section", RFC 6982, July 2013
    
       [RFC7015] B. Trammell, A. Wagner, and B. Claise, "Flow
                 Aggregation for the IP Flow Information Export
                 (IPFIX) Protocol", RFC 7015, September 2013
    
       [ACPI] "Advanced Configuration and Power Interface
                 Specification", http://www.acpi.info/spec30b.htm
    
       [IEEE1621]  "Standard for User Interface Elements in Power
                 Control of Electronic Devices Employed in
                 Office/Consumer Environments", IEEE 1621,
                 December 2004
    
       [ITU-T-M-3400] TMN Recommendation on Management Functions
                 (M.3400), 1997
    
       [NMF] "Network Management Fundamentals", Alexander Clemm,
                 ISBN: 1-58720-137-2, 2007
    
       [TMN] "TMN Management Functions : Performance Management",
                 ITU-T M.3400
    
    
    
    
    
    Claise, et al.        Expires October 28, 2014     [Page 45]
    

    Internet-Draft             EMAN Framework          April 2014
    
       [IEEE100] "The Authoritative Dictionary of IEEE Standards
                 Terms"
                 http://ieeexplore.ieee.org/xpl/mostRecentIssue.js
                 p?punumber=4116785
    
       [ISO50001] "ISO 50001:2011 Energy management systems -
                 Requirements with guidance for use",
                 http://www.iso.org/
    
       [IEC60050] International Electrotechnical Vocabulary
                 http://www.electropedia.org/iev/iev.nsf/welcome?o
                 penform
    
       [IEC61850] Power Utility Automation,
                 http://www.iec.ch/smartgrid/standards/
    
    
       [IEC61850-7-2] Abstract communication service interface
                 (ACSI), http://www.iec.ch/smartgrid/standards/
    
       [IEC61850-7-4] Compatible logical node classes and data
                 classes, http://www.iec.ch/smartgrid/standards/
    
       [DMTF] "Power State Management Profile DMTF  DSP1027
                 Version 2.0"  December 2009
                 http://www.dmtf.org/sites/default/files/standards
                 /documents/DSP1027_2.0.0.pdf
    
       [IPENERGY] R. Aldrich, J. Parello "IP-Enabled Energy
                 Management", 2010, Wiley Publishing
    
       [X.700]  CCITT Recommendation X.700 (1992), Management
                 framework for Open Systems Interconnection (OSI)
                 for CCITT applications
    
       [ASHRAE-201] "ASHRAE Standard Project Committee 201
                       (SPC 201)Facility Smart Grid Information
                       Model", http://spc201.ashraepcs.org
    
       [CHEN] "The Entity-Relationship Model: Toward a Unified
                 View of Data",  Peter Pin-shan Chen, ACM
                 Transactions on Database Systems, 1976
    
       [CISCO-EW] "Cisco EnergyWise Design Guide",  John Parello,
                 Roland Saville, Steve Kramling, Cisco Validated
                 Designs, September 2010,
                 http://www.cisco.com/en/US/docs/solutions/Enterpr
                 ise/Borderless_Networks/Energy_Management/energyw
                 isedg.html
    
    
    Claise, et al.        Expires October 28, 2014     [Page 46]
    

    Internet-Draft             EMAN Framework          April 2014
    
    
    
    
    
    14. Acknowledgments
    
       The authors would like to thank Michael Brown for his
       editorial work improving the text dramatically. Thanks to
       Rolf Winter for his feedback and to Bill Mielke for
       feedback and very detailed review. Thanks to Bruce Nordman
       for brainstorming with numerous conference calls and
       discussions. Finally, the authors would like to thank the
       EMAN chairs: Nevil Brownlee, Bruce Nordman, and Tom Nadeau.
    
       This document was prepared using 2-Word-v2.0.template.dot.
    
    Appendix A.
                Information Model Listing
    
       EnergyObject (Class)
    
       r  index         Integer           An RFC6933
                                           entPhysicalIndex
    
       w  name          String            An RFC6933
                                           entPhysicalName
    
       r  identifier    uuid              An [RFC6933]
                                           entPhysicalUUID
    
       rw alternatekey  String            A manufacturer defined
                                           string that can be
                                           used to identify the
                                           Energy Object
    
       rw domainName    String            The name of an Energy
                                           Management domain for
                                           the Energy Object
    
       rw role          String            An administratively
                                           assigned name to
                                           indicate the purpose
                                           an Energy Object
                                           serves in the network
    
       rw keywords      String            A list of keywords or
           [0..n]                          tags that can be used
                                           to group Energy
                                           Objects for reporting
    
    
    
    Claise, et al.        Expires October 28, 2014     [Page 47]
    

    Internet-Draft             EMAN Framework          April 2014
    
                                           or searching
    
       rw importance    Integer           Specifies a ranking of
                                           how important the
                                           Energy Object is (on a
                                           scale of 1 to 100)
                                           compared with other
                                           Energy Objects
    
       rw relationships Relationship      A list of
           [0..n]                          relationships between
                                           this Energy Object and
                                           other Energy Objects
    
       r  nameplate     Nameplate         The nominal
                                           PowerMeasurement of
                                           the Energy Object as
                                           specified by the
                                           device manufacturer
    
       r  power         PowerMeasurement  The present power
                                           measurement of the
                                           Energy Object
    
       r  energy        EnergyMeasurment  The present energy
                                           measurement for the
                                           Energy Object
    
       r  demand        DemandMeasurement The present demand
                                           measurement for the
                                           Energy Object
    
       r  powerControl  PowerStateSet     A list of Power States
           [0..n]                          Sets the Energy Object
                                           supports
    
    
    
       PowerInterface (Class) inherits from and specializes
       EnergyObject
    
       r  eoIfType      Enumeration      Indicates if the Power
                                          Interface is an -
                                          inlet; outlet; both
    
    
    
    
    
    
    
    Claise, et al.        Expires October 28, 2014     [Page 48]
    

    Internet-Draft             EMAN Framework          April 2014
    
       Device (Class) inherits from and specializes EnergyObject
    
       rw eocategory      Enumeration    Broadly indicates if
                                          the Device is a
                                          producer consumer meter
                                          distributor or store of
                                          energy
    
       r  powerInterfaces PowerInterface A list of
           [0..n]                         PowerInterfaces
                                          contained in this
                                          Device
    
       r  components      Component      A list of Components
           [0..n]                         contained in this
                                          Device
    
    
    
       Component (Class) inherits from and specializes
       EnergyObject
    
       rw eocategory      Enumeration    Broadly indicates if
                                          the Component is a
                                          producer consumer meter
                                          distributor or store of
                                          energy
    
       r  powerInterfaces PowerInterface A list of
           [0..n]                         PowerInterfaces
                                          contained in this
                                          Component
    
       r  components      Component      A list of Components
           [0..n]                         contained in this
                                          Component
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    Claise, et al.        Expires October 28, 2014     [Page 49]
    

    Internet-Draft             EMAN Framework          April 2014
    
       Nameplate (Class)
    
       r  nominalPower  PowerMeasuremen  The nominal power of
                         t                the Energy Object as
                                          specified by the device
                                          manufacturer
    
       rw details       URI              an [RFC3986] URI that
                                          links to manufacturer
                                          information about the
                                          nominal power of a
                                          device
    
    
       Relationship (Class)
    
       rw relationshipType   Enumeratio  A description of the
                               n           relationhip indicating
                                           - meters; meteredby;
                                           powers; poweredby;
                                           aggregates;
                                           aggregatedby
    
       rw relationshipObject uuid        An [RFC6933]
                                           entPhysicalUUID that
                                           indicates the other
                                           participating Energy
                                           Object in the
                                           relationship
    
    
    
       Measurement (Class)
    
       r  multiplier  Enumeration  The magnitude of the
                                     Measurement in the range -
                                     24..24
    
       r  caliber     Enumeration  Specifies how the Measurement
                                     was obtained - actual;
                                     estimated; static
    
       r  accuracy    Enumeration  Specifies the accuracy of the
                                     measurement if applicable as
                                     0..10000 indicating hundreds
                                     of percent
    
    
    
    
    
    Claise, et al.        Expires October 28, 2014     [Page 50]
    

    Internet-Draft             EMAN Framework          April 2014
    
       PowerMeasurement (Class) inherits from and specializes
       Measurement
    
       r value          Long           A measurement value of
                                         power
    
       r units          "W"            The units of measure for
                                         the power - "Watts"
    
       r powerAttribute PowerAttribute  Measurement of the
                                         electrical current;
                                         voltage; phase and/or
                                         frequencies for the
                                         PowerMeasurement
    
    
    
       EnergyMeasurement (Class) inherits from and specializes
       Measurement
    
       r startTime  Time         Specifies the start time of the
                                  EnergyMeasurement interval
    
       r units      "kWh"        The units of measure for the
                                  energy - kilowatt hours
    
       r provided   Long         A measurement of energy
                                  provided
    
       r used       Long         A measurement of energy used /
                                  consumed
    
       r produced   Long         A measurement of energy
                                  produced
    
       r stored     Long         A measurement of energy stores
    
    
    
       TimedMeasurement (Class) inherits from and specializes
       Measurement
    
       r  startTime timestamp    A start time of a measurement
    
       r  value     Measurement  A measurement value
    
       r  maximum   Measurement  A maximum value measured since a
                                  previous timestamp
    
    
    
    Claise, et al.        Expires October 28, 2014     [Page 51]
    

    Internet-Draft             EMAN Framework          April 2014
    
    
    
       TimeInterval (Class)
    
       r  value     Long        a value of time
    
       r  units     Enumeration  a magnitude of time express as
                                  seconds with an SI prefix
                                  (miliseconds etc)
    
    
    
       DemandMeasurement (Class) inherits from and specializes
       Measurement
    
       rw intervalLength TimeInterval     The length of time
                                           over which to compute
                                           average energy
    
       rw intervals      Long             The number of
                                           intervals that can be
                                           measured
    
       rw intervalMode   Enumeration      The mode of interval
                                           measurement as -
                                           periodic; sliding;
                                           total
    
       rw intervalWindow TimeInterval     The duration between
                                           the starting time of
                                           one sliding window and
                                           the next starting time
    
       rw sampleRate     TimeInterval     The sampling rate at
                                           which to poll power in
                                           order to compute
                                           demand
    
       rw status         Enumeration      a control to start or
                                           stop demand
                                           measurement as -
                                           active; inactive
    
       r  measurements[0.TimedMeasurement a collection of
           .n]                             TimedMeasurements to
                                           compute demand
    
    
    
    
    
    Claise, et al.        Expires October 28, 2014     [Page 52]
    

    Internet-Draft             EMAN Framework          April 2014
    
    
       PowerStateSet (Class)
    
       r  powerSetIdentifier Integer      an IANA assigned value
                                           indicating a Power
                                           State Set
    
       r  name               String       A Power State Set name
    
       r  powerStates [0..n] PowerState   a set of Power States
                                           for the given
                                           identifier
    
       rw operState          Integer      The current
                                           operational Power
                                           State
    
       rw adminState         Integer      The desired Power
                                           State
    
       rw reason             String       Describes the reason
                                           for the adminState
    
       r  configuredTime     timestamp    Indicates the time of
                                           the desired Power
                                           State
    
    
    
       PowerState (Class)
    
       r  powerStateIdentifier Integer  an IANA assigned value
                                          indicating a Power State
    
       r  name                 String   A name for the Power
                                          State
    
       r  cardinality          Integer  A value indicating an
                                          ordering of the Power
                                          State
    
       rw maximumPower         PowerMea indicates the maximum
                                surement power for the Energy
                                          Object at this Power
                                          State
    
       r  totalTimeInState     Time     Indicates the total time
                                          an Energy Object has
                                          been in this Power State
    
    
    Claise, et al.        Expires October 28, 2014     [Page 53]
    

    Internet-Draft             EMAN Framework          April 2014
    
                                          since last reset
    
       r  entryCount           Long     Indicates the number of
                                          time the Energy Object
                                          has entered changed to
                                          this state
    
    
    
       PowerAttribute (Class)
    
       r acQuality  ACQuality  Describes AC Power Attributes for
                                a Measurement
    
    
    
       ACQuality (Class)
    
       r acConfiguration    Enumera Describes the physical
                             tion    configuration of
                                      alternating current as
                                      single phase (SNGL) three
                                      phase delta (DEL) or three
                                      phase Y (WYE)
    
       r avgVoltage         Long    The average of the voltage
                                      measured over an integral
                                      number of AC cycles
                                      [IEC61850-7-4] 'Vol'
    
       r avgCurrent         Long    The current per phase
                                      [IEC61850-7-4] 'Amp'
    
       r frequency          Long    Basic frequency of the AC
                                      circuit [IEC61850-7-4] 'Hz'
    
       r unitMultiplier     Integer Magnitude of watts for the
                                      usage value in this
                                      instance
    
       r accuracy           Integer Percentage value in 100ths
                                      of a percent representing
                                      the presumed accuracy of
                                      active; reactive; and
                                      apparent power in this
                                      instance
    
       r totalActivePower   Long    A measured value of the
                                      actual power delivered to
    
    
    Claise, et al.        Expires October 28, 2014     [Page 54]
    

    Internet-Draft             EMAN Framework          April 2014
    
                                      or consumed by the load
                                      [IEC61850-7-4] 'TotW'
    
       r totalReactivePower Long    A measured value of the
                                      reactive portion of the
                                      apparent power [IEC61850-7-
                                      4] 'TotVAr'
    
       r totalApparentPower Long    A measured value of the
                                      voltage and current which
                                      determines the apparent
                                      power as the vector sum of
                                      real and reactive power
                                      [IEC61850-7-4] 'TotVA'
    
       r totalPowerFactor   Long    A measured value of the
                                      ratio of the real power
                                      flowing to the load versus
                                      the apparent power
                                      [IEC61850-7-4] 'TotPF'
    
       r phases [0..2]      ACPhase A description of the three
                                      phase power
    
    
    
       ACPhase (Class)
    
       r phaseIndex    Long  A phase angle typically
                               corresponding to - 0; 120; 240
    
       r avgCurrent    Long  A measured value of the current per
                               phase [IEC61850-7-4] 'A'
    
       r activePower   Long  A measured value of the actual
                               power delivered to or consumed by
                               the load [IEC61850-7-4] 'W'
    
       r reactivePower Long  A measured value of the reactive
                               portion of the apparent power
                               [IEC61850-7-4] 'VAr'
    
       r apparentPower Long  A measured value of the active plus
                               reactive power [IEC61850-7-4] 'VA'
    
       r powerFactor   Long  A measure ratio of the real power
                               flowing to the load versus the
                               apparent power for this phase
    
    
    
    Claise, et al.        Expires October 28, 2014     [Page 55]
    

    Internet-Draft             EMAN Framework          April 2014
    
                               [IEC61850-7-4] 'PF'
    
    
    
    
    
    
       DelPhase (Class) inherits from and specializes ACPhase
    
       r phaseToNextPhas  Long  A measured value of phase to
          eVoltage               next phase voltages where the
                                 next phase is [IEC61850-7-4]
                                 'PPV'
    
       r thdVoltage       Long  A calculated value for the
                                 voltage total harmonic disortion
                                 for phase to next phase. Method
                                 of calculation is not specified
                                 [IEC61850-7-4] 'ThdPPV'
    
       r thdCurrent       Long  A calculated value for the
                                 voltage total harmonic disortion
                                 (THD) for phase to phase. Method
                                 of calculation is not specified
                                 [IEC61850-7-4] 'ThdPPV'
    
    
    
       WYEPhase (Class) inherits from and specializes ACPhase
    
       r phaseToNeutral  Long A measured value of phase to
          Voltage              neutral voltage [IEC61850-7-4]
                               'PhV'
    
       r thdCurrent      Long A measured value of phase currents
                               [IEC61850-7-4] 'A'
    
       r thdVoltage      Long A calculated value of the voltage
                               total harmonic distortion (THD)
                               for phase to neutral [IEC61850-7-
                               4] 'ThdPhV'
    
    
    Authors' Addresses
    
       John Parello
       Cisco Systems, Inc.
       3550 Cisco Way
       San Jose, California 95134
    
    
    Claise, et al.        Expires October 28, 2014     [Page 56]
    

    Internet-Draft             EMAN Framework          April 2014
    
       US
    
       Phone: +1 408 525 2339
       Email: jparello@cisco.com
    
       Benoit Claise
       Cisco Systems, Inc.
       De Kleetlaan 6a b1
       Diegem 1813
       BE
    
       Phone: +32 2 704 5622
       Email: bclaise@cisco.com
    
       Brad Schoening
       44 Rivers Edge Drive
       Little Silver, NJ 07739
       US
    
       Phone:
       Email: brad.schoening@verizon.net
    
       Juergen Quittek
       NEC Europe Ltd.
       Network Laboratories
       Kurfuersten-Anlage 36
       69115 Heidelberg
       Germany
    
       Phone: +49 6221 90511 15
       EMail: quittek@netlab.nec.de
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    Claise, et al.        Expires October 28, 2014     [Page 57]
    

Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/