Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7326

Energy Management Framework

Pages: 54
Informational
Part 2 of 2 – Pages 29 to 54
First   Prev   None

Top   ToC   RFC7326 - Page 29   prevText

7. Energy Management Information Model

This section presents an information model expression of the concepts in this framework as a reference for implementers. The information model is implemented as MIB modules in the different related IETF EMAN documents. However, other programming structures with different data models could be used as well. Data modeling specifications of this information model may, where needed, specify which attributes are required or optional. Syntax Unified Modeling Language (UML) Construct [ISO-IEC-19501-2005] Equivalent Notation -------------------- ---------------------------------- Notes // Notes Class (Generalization) CLASS name {member..} Subclass (Specialization) CLASS subclass EXTENDS superclass {member..} Class Member (Attribute) attribute : type
Top   ToC   RFC7326 - Page 30
   Model

      CLASS EnergyObject {

            // identification / classification
            index        : int
            name         : string
            identifier   : uuid
            alternatekey : string

            // context
            domainName      : string
            role            : string
            keywords [0..n] : string
            importance      : int

            // relationship
            relationships [0..n] : Relationship

            // measurements
            nameplate    : Nameplate
            power        : PowerMeasurement
            energy       : EnergyMeasurement
            demand       : DemandMeasurement

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

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

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

      CLASS Component EXTENDS EnergyObject {
            eocategory             : enum { producer, consumer, meter,
      distributor, store }
            powerInterfaces [0..n] : PowerInterface
            components [0..n]      : Component
      }
Top   ToC   RFC7326 - Page 31
      CLASS Nameplate {
            nominalPower : PowerMeasurement
            details      : URI
      }

      CLASS Relationship {
            relationshipType    : enum { meters, meteredby, powers,
      poweredby, aggregates, aggregatedby }
            relationshipObject  : uuid
      }

      CLASS Measurement {
            multiplier : enum { -24..24 }
            caliber    : enum { actual, estimated, static }
            accuracy   : enum { 0..10000 } // hundreds of percent
      }

      CLASS PowerMeasurement EXTENDS Measurement {
            value          : long
            units          : "W"
            powerAttribute : PowerAttribute
      }

      CLASS EnergyMeasurement EXTENDS Measurement {
            startTime : time
            units     : "kWh"
            provided  : long
            used      : long
            produced  : long
            stored    : long

      }

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

      CLASS TimeInterval {
            value      : long
            units      : enum { seconds, milliseconds,... }
      }
Top   ToC   RFC7326 - Page 32
      CLASS DemandMeasurement EXTENDS Measurement {
            intervalLength      : TimeInterval
            intervals           : long
            intervalMode        : enum { periodic, sliding, total }
            intervalWindow      : TimeInterval
            sampleRate          : TimeInterval
            status              : enum { active, inactive }
            measurements [0..n] : TimedMeasurements
      }

      CLASS PowerStateSet {
            powerSetIdentifier : int
            name               : string
            powerStates [0..n] : PowerState
            operState          : int
            adminState         : int
            reason             : string
            configuredTime     : timestamp
      }

      CLASS PowerState {
            powerStateIdentifier : int
            name                 : string
            cardinality          : int
            maximumPower         : PowerMeasurement
            totalTimeInState     : time
            entryCount           : long
      }

      CLASS PowerAttribute {
            acQuality  : ACQuality
      }

      CLASS ACQuality {
            acConfiguration    : enum { SNGL, DEL, WYE }
            avgVoltage         : long
            avgCurrent         : long
            thdCurrent         : long
            frequency          : long
            unitMultiplier     : int
            accuracy           : int
            totalActivePower   : long
            totalReactivePower : long
            totalApparentPower : long
            totalPowerFactor   : long
      }
Top   ToC   RFC7326 - Page 33
      CLASS DelPhase EXTENDS ACQuality {
            phaseToNextPhaseVoltage : long
            thdVoltage              : long
      }

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

8. Modeling Relationships between Devices

In this section, we give examples of how to use the EMAN information model to model physical topologies. Where applicable, we show how the framework can be applied when devices can be modeled with Power Interfaces. We also show how the framework can be applied when devices cannot be modeled with Power Interfaces but only monitored or controlled as a whole. For instance, a PDU may only be able to measure power and energy for the entire unit without the ability to distinguish among the inlets or outlets.

8.1. Power Source Relationship

The Power Source Relationship is used to model the interconnections between devices, components, and/or Power Interfaces to indicate the source of energy for a device. In the following examples, we show variations on modeling the reference topologies using relationships. Given for all cases: Device W: A computer with one power supply. Power Interface 1 is an inlet for Device W. Device X: A computer with two power supplies. Power Interface 1 and Power Interface 2 are both inlets for Device X. Device Y: A PDU with multiple Power Interfaces numbered 0..10. Power Interface 0 is an inlet, and Power Interfaces 1..10 are outlets. Device Z: A PDU with multiple Power Interfaces numbered 0..10. Power Interface 0 is an inlet, and Power Interfaces 1..10 are outlets.
Top   ToC   RFC7326 - Page 34
   Case 1: Simple Device with one Source

      Physical Topology:

         o  Device W inlet 1 is plugged into Device Y outlet 8.

      With Power Interfaces:

         o  Device W has an Energy Object representing the computer
            itself as well as one Power Interface defined as an inlet.

         o  Device Y would have an Energy Object representing the PDU
            itself (the Device), with Power Interface 0 defined as an
            inlet and Power Interfaces 1..10 defined as outlets.

         The interfaces of the devices would have a Power Source
         Relationship such that:

         Device W inlet 1 is powered by Device Y outlet 8.

            +-------+------+       poweredBy +------+----------+
            | PDU Y | PI 8 |-----------------| PI 1 | Device W |
            +-------+------+ powers          +------+----------+

      Without Power Interfaces:

         o  Device W has an Energy Object representing the computer.

         o  Device Y would have an Energy Object representing the PDU.

         The devices would have a Power Source Relationship such that:

         Device W is powered by Device Y.

            +----------+       poweredBy +------------+
            |  PDU Y   |-----------------|  Device W  |
            +----------+ powers          +------------+
Top   ToC   RFC7326 - Page 35
   Case 2: Multiple Inlets

      Physical Topology:

      o  Device X inlet 1 is plugged into Device Y outlet 8.

      o  Device X inlet 2 is plugged into Device Y outlet 9.

      With Power Interfaces:

         o  Device X has an Energy Object representing the computer
            itself.  It contains two Power Interfaces defined as inlets.

         o  Device Y would have an Energy Object representing the PDU
            itself (the Device), with Power Interface 0 defined as an
            inlet and Power Interfaces 1..10 defined as outlets.

         The interfaces of the devices would have a Power Source
         Relationship such that:

         Device X inlet 1 is powered by Device Y outlet 8.

         Device X inlet 2 is powered by Device Y outlet 9.

            +-------+------+        poweredBy+------+----------+
            |       | PI 8 |-----------------| PI 1 |          |
            |       |      |powers           |      |          |
            | PDU Y +------+        poweredBy+------+ Device X |
            |       | PI 9 |-----------------| PI 2 |          |
            |       |      |powers           |      |          |
            +-------+------+                 +------+----------+

      Without Power Interfaces:

         o  Device X has an Energy Object representing the computer.
            Device Y has an Energy Object representing the PDU.

         The devices would have a Power Source Relationship such that:

         Device X is powered by Device Y.

            +----------+       poweredBy +------------+
            |  PDU Y   |-----------------|  Device X  |
            +----------+ powers          +------------+
Top   ToC   RFC7326 - Page 36
   Case 3: Multiple Sources

      Physical Topology:

      o  Device X inlet 1 is plugged into Device Y outlet 8.

      o  Device X inlet 2 is plugged into Device Z outlet 9.

      With Power Interfaces:

         o  Device X has an Energy Object representing the computer
            itself.  It contains two Power Interfaces defined as inlets.

         o  Device Y would have an Energy Object representing the PDU
            itself (the Device), with Power Interface 0 defined as an
            inlet and Power Interfaces 1..10 defined as outlets.

         o  Device Z would have an Energy Object representing the PDU
            itself (the Device), with Power Interface 0 defined as an
            inlet and Power Interfaces 1..10 defined as outlets.

         The interfaces of the devices would have a Power Source
         Relationship such that:

         Device X inlet 1 is powered by Device Y outlet 8.

         Device X inlet 2 is powered by Device Z outlet 9.

            +-------+------+        poweredBy+------+----------+
            | PDU Y | PI 8 |-----------------| PI 1 |          |
            |       |      |powers           |      |          |
            +-------+------+                 +------+          |
                                                    | Device X |
            +-------+------+        poweredBy+------+          |
            | PDU Z | PI 9 |-----------------| PI 2 |          |
            |       |      |powers           |      |          |
            +-------+------+                 +------+----------+

      Without Power Interfaces:

         o  Device X has an Energy Object representing the computer.
            Devices Y and Z would both have respective Energy Objects
            representing each entire PDU.
Top   ToC   RFC7326 - Page 37
         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.
Top   ToC   RFC7326 - Page 38
   A Metering Relationship can occur between devices that are not
   directly connected, as shown in the following figure:

                          +---------------+
                          |   Device 1    |
                          +---------------+
                          |      PI       |
                          +---------------+
                                  |
                          +---------------+
                          |     Meter     |
                          +---------------+
                                  .
                                  .
                                  .
                 meters        meters           meters
           +----------+   +----------+   +-----------+
           | Device A |   | Device B |   | Device C  |
           +----------+   +----------+   +-----------+

   An analogy to communications networks would be modeling connections
   between servers (meters) and clients (devices) when the complete
   Layer 2 topology between the servers and clients is not known.

8.3. Aggregation Relationship

Some devices can act as Aggregation points for other devices. For example, a PDU controller device may contain the summation of power and energy readings for many PDU devices. The PDU controller will have aggregate values for power and energy for a group of PDU devices. This Aggregation is independent of the physical power or communication topology. The functions that the Aggregation point may perform include the calculation of values such as average, count, maximum, median, minimum, or the listing (collection) of the Aggregation values, etc. Based on IETF experience gained on Aggregations [RFC7015], the Aggregation function in the EMAN framework is limited to the summation. When Aggregation occurs across a set of entities, values to be aggregated may be missing for some entities. The EMAN framework does not specify how these should be treated, as different implementations may have good reason to take different approaches. One common treatment is to define the Aggregation as missing if any of the
Top   ToC   RFC7326 - Page 39
   constituent elements are missing (useful to be most precise).
   Another is to treat the missing value as zero (useful to have
   continuous data streams).

   The specifications of Aggregation functions are out of the scope of
   the EMAN framework but must be clearly specified by the equipment
   vendor.

9. Relationship to Other Standards

This Energy Management framework uses, as much as possible, existing standards, especially with respect to information modeling and data modeling [RFC3444]. The data model for power- and energy-related objects is based on [IEC61850]. Specific examples include: o The scaling factor, which represents Energy Object usage magnitude, conforms to the [IEC61850] definition of unit multiplier for the SI (System International) units of measure. o The electrical characteristics are based on the ANSI and IEC Standards, which require that we use an accuracy class for power measurement. ANSI and IEC define the following accuracy classes for power measurement: - IEC 62053-22 and 60044-1 classes 0.1, 0.2, 0.5, 1, and 3. - ANSI C12.20 classes 0.2 and 0.5. o The electrical characteristics and quality adhere closely to the [IEC61850-7-4] standard for describing AC measurements. o The Power State definitions are based on the DMTF Power State Profile and ACPI models, with operational state extensions.

10. Security Considerations

Regarding the data attributes specified here, some or all may be considered sensitive or vulnerable in some network environments. Reading or writing these attributes without proper protection such as encryption or access authorization will have negative effects on network capabilities. Event logs for audit purposes on configuration and other changes should be generated according to current
Top   ToC   RFC7326 - Page 40
   authorization, audit, and accounting principles to facilitate
   investigations (compromise or benign misconfigurations) or any
   reporting requirements.

   The information and control capabilities specified in this framework
   could be exploited, to the detriment of a site or deployment.
   Implementers of the framework SHOULD examine and mitigate security
   threats with respect to these new capabilities.

   "User-based Security Model (USM) for version 3 of the Simple Network
   Management Protocol (SNMPv3)" [RFC3414] presents a good description
   of threats and mitigations for SNMPv3 that can be used as a guide for
   implementations of this framework using other protocols.

10.1. Security Considerations for SNMP

Readable objects in MIB modules (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is important to control GET and/or NOTIFY access to these objects and possibly to encrypt the values of these objects when sending them over the network via SNMP. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. For example: o Unauthorized changes to the Energy Management Domain or business context of a device will result in misreporting or interruption of power. o Unauthorized changes to a Power State will disrupt the power settings of the different devices and therefore the state of functionality of the respective devices. o Unauthorized changes to the demand history will disrupt proper accounting of energy usage. With respect to data transport, SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example, by using IPsec), there is still no secure control over who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in these MIB modules. It is recommended that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3411]), including full support for the SNMPv3 cryptographic mechanisms (for authentication and confidentiality).
Top   ToC   RFC7326 - Page 41
   Further, deployment of SNMP versions prior to SNMPv3 is not
   recommended.  Instead, it is recommended to deploy SNMPv3 and to
   enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of these MIB modules is properly configured to give access
   to the objects only to those principals (users) that have legitimate
   rights to GET or SET (change/create/delete) them.

11. IANA Considerations

11.1. IANA Registration of New Power State Sets

This document specifies an initial set of Power State Sets. The list of these Power State Sets with their numeric identifiers is given in Section 6. IANA maintains the lists of Power State Sets. New assignments for a Power State Set are administered by IANA through Expert Review [RFC5226], i.e., review by one of a group of experts designated by an IETF Area Director. The group of experts must check the requested state for completeness and accuracy of the description. A pure vendor-specific implementation of a Power State Set shall not be adopted, since it would lead to proliferation of Power State Sets. Power States in a Power State Set are limited to 255 distinct values. A new Power State Set must be assigned the next available numeric identifier that is a multiple of 256.

11.1.1. IANA Registration of the IEEE1621 Power State Set

This document specifies a set of values for the IEEE1621 Power State Set [IEEE1621]. The list of these values with their identifiers is given in Section 6.5.2. IANA created a new registry for IEEE1621 Power State Set identifiers and filled it with the initial list of identifiers. New assignments (or, potentially, deprecation) for the IEEE1621 Power State Set are administered by IANA through Expert Review [RFC5226].

11.1.2. IANA Registration of the DMTF Power State Set

This document specifies a set of values for the DMTF Power State Set [DMTF]. The list of these values with their identifiers is given in Section 6.5.3. IANA has created a new registry for DMTF Power State Set identifiers and filled it with the initial list of identifiers. New assignments (or, potentially, deprecation) for the DMTF Power State Set are administered by IANA through Expert Review [RFC5226].
Top   ToC   RFC7326 - Page 42
   The group of experts must check for conformance with the DMTF
   standard [DMTF] in addition to checking for completeness and accuracy
   of the description.

11.1.3. IANA Registration of the EMAN Power State Set

This document specifies a set of values for the EMAN Power State Set. The list of these values with their identifiers is given in Section 6.5.4. IANA has created a new registry for EMAN Power State Set identifiers and filled it with the initial list of identifiers. New assignments (or, potentially, deprecation) for the EMAN Power State Set are administered by IANA through Expert Review [RFC5226].

11.2. Updating the Registration of Existing Power State Sets

With the evolution of standards, over time, it may be important to deprecate some of the existing Power State Sets, or to add or deprecate some Power States within a Power State Set. The registrant shall post an Internet-Draft with the clear specification on deprecation of Power State Sets or Power States registered with IANA. The deprecation or addition shall be administered by IANA through Expert Review [RFC5226], i.e., review by one of a group of experts designated by an IETF Area Director. The process should also allow for a mechanism for cases where others have significant objections to claims regarding the deprecation of a registration.
Top   ToC   RFC7326 - Page 43

12. References

12.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, January 2003. [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M. Chandramouli, "Entity MIB (Version 4)", RFC 6933, May 2013. [RFC6988] Quittek, J., Ed., Chandramouli, M., Winter, R., Dietz, T., and B. Claise, "Requirements for Energy Management", RFC 6988, September 2013. [ISO-IEC-19501-2005] ISO/IEC 19501:2005, Information technology, Open Distributed Processing -- Unified Modeling Language (UML) Version 1.4.2, January 2005.
Top   ToC   RFC7326 - Page 44

12.2. Informative References

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC7015] Trammell, B., Wagner, A., and B. Claise, "Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol", RFC 7015, September 2013. [ACPI] "Advanced Configuration and Power Interface Specification", October 2006, <http://www.acpi.info/spec30b.htm>. [IEEE1621] "Standard for User Interface Elements in Power Control of Electronic Devices Employed in Office/Consumer Environments", IEEE 1621, December 2004. [NMF] Clemm, A., "Network Management Fundamentals", ISBN-10: 1-58720-137-2, Cisco Press, November 2006. [TMN] International Telecommunication Union, "TMN management functions", ITU-T Recommendation M.3400, February 2000. [IEEE100] "The Authoritative Dictionary of IEEE Standards Terms", <http://ieeexplore.ieee.org/xpl/ mostRecentIssue.jsp?punumber=4116785>. [ISO50001] "ISO 50001:2011 Energy management systems -- Requirements with guidance for use", June 2011, <http://www.iso.org/>. [IEC60050] "International Electrotechnical Vocabulary", <http://www.electropedia.org/iev/iev.nsf/ welcome?openform>. [IEC61850] "Power Utility Automation", <http://www.iec.ch/smartgrid/standards/>. [IEC61850-7-2] "Abstract communication service interface (ACSI)", <http://www.iec.ch/smartgrid/standards/>. [IEC61850-7-4] "Compatible logical node classes and data classes", <http://www.iec.ch/smartgrid/standards/>.
Top   ToC   RFC7326 - Page 45
   [DMTF]     "Power State Management Profile", DMTF DSP1027
              Version 2.0.0, December 2009,
              <http://www.dmtf.org/sites/default/files/standards/
              documents/DSP1027_2.0.0.pdf>.

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

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

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

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

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

13. Acknowledgments

The authors would like to thank Michael Brown for his editorial work, which improved the text dramatically. Thanks to Rolf Winter for his feedback, and to Bill Mielke for his feedback and very detailed review. Thanks to Bruce Nordman for brainstorming, with numerous conference calls and discussions. Finally, the authors would like to thank the EMAN chairs: Nevil Brownlee, Bruce Nordman, and Tom Nadeau.
Top   ToC   RFC7326 - Page 46

Appendix A. Information Model Listing

A. EnergyObject (Class): r index Integer An [RFC6933] entPhysicalIndex w name String An [RFC6933] entPhysicalName r identifier uuid An [RFC6933] entPhysicalUUID rw alternatekey String A manufacturer-defined string that can be used to identify the Energy Object rw domainName String The name of an Energy Management Domain for the Energy Object rw role String An administratively assigned name to indicate the purpose an Energy Object serves in the network rw keywords String A list of keywords or [0..n] tags that can be used to group Energy Objects for reporting or searching rw importance Integer Specifies a ranking of how important the Energy Object is (on a scale of 1 to 100) compared with other Energy Objects rw relationships Relationship A list of relationships between [0..n] this Energy Object and other Energy Objects r nameplate Nameplate The nominal PowerMeasurement of the Energy Object as specified by the device manufacturer r power PowerMeasurement The present power measurement of the Energy Object r energy EnergyMeasurement The present energy measurement for the Energy Object r demand DemandMeasurement The present demand measurement for the Energy Object
Top   ToC   RFC7326 - Page 47
   r  powerControl  PowerStateSet      A list of Power States Sets the
      [0..n]                           Energy Object supports


   B. PowerInterface (Class) inherits from EnergyObject:

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


   C. Device (Class) inherits from EnergyObject:

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

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

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


   D. Component (Class) inherits from EnergyObject:

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

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

   r  components       Component       A list of components contained
      [0..n]                           in this component
Top   ToC   RFC7326 - Page 48
   E. Nameplate (Class):

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

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


   F. Relationship (Class):

   rw relationshipType    Enumeration   A description of the
                                        relationship, indicating
                                        meters, meteredby, powers,
                                        poweredby, aggregates, or
                                        aggregatedby

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


   G. Measurement (Class):

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

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

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


   H. PowerMeasurement (Class) inherits from Measurement:

   r value          Long             A measurement value of
                                     power

   r units          "W"              The units of measure for
                                     the power -- "Watts"
Top   ToC   RFC7326 - Page 49
   r powerAttribute PowerAttribute   Measurement of the electrical
                                     current -- voltage, phase, and/or
                                     frequencies for the
                                     PowerMeasurement


   I. EnergyMeasurement (Class) inherits from Measurement:

   r startTime  Time          Specifies the start time of the
                              EnergyMeasurement interval

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

   r provided   Long          A measurement of energy provided

   r used       Long          A measurement of energy used/consumed

   r produced   Long          A measurement of energy produced

   r stored     Long          A measurement of energy stored


   J. TimedMeasurement (Class) inherits from Measurement:

   r  startTime timestamp     A start time of a measurement

   r  value     Measurement   A measurement value

   r  maximum   Measurement   A maximum value measured since a previous
                              timestamp


   K. TimeInterval (Class):

   r  value     Long          A value of time

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


   L. DemandMeasurement (Class) inherits from Measurement:

   rw intervalLength  TimeInterval     The length of time over which to
                                       compute average energy

   rw intervals       Long             The number of intervals that can
                                       be measured
Top   ToC   RFC7326 - Page 50
   rw intervalMode    Enumeration      The mode of interval
                                       measurement -- periodic, sliding,
                                       or total

   rw intervalWindow  TimeInterval     The duration between the starting
                                       time of one sliding window and
                                       the next starting time

   rw sampleRate      TimeInterval     The sampling rate at which to
                                       poll power in order to compute
                                       demand

   rw status          Enumeration      A control to start or stop demand
                                       measurement -- active or inactive

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


   M. PowerStateSet (Class):

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

   r  name               String        A Power State Set name

   r  powerStates        PowerState    A set of Power States for the
      [0..n]                           given identifier

   rw operState          Integer       The current operational Power
                                       State

   rw adminState         Integer       The desired Power State

   rw reason             String        Describes the reason
                                       for the adminState

   r  configuredTime     timestamp     Indicates the time of
                                       the desired Power State


   N. PowerState (Class):

   r  powerStateIdentifier Integer           An IANA-assigned value
                                             indicating a Power State

   r  name                 String            A name for the Power State
Top   ToC   RFC7326 - Page 51
   r  cardinality          Integer           A value indicating an
                                             ordering of the Power State

   rw maximumPower         PowerMeasurement  Indicates the maximum power
                                             for the Energy Object at
                                             this Power State

   r  totalTimeInState     Time              Indicates the total time
                                             an Energy Object has been
                                             in this Power State since
                                             the last reset

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


   O. PowerAttribute (Class):

   r acQuality          ACQuality    Describes AC Power Attributes for
                                     a Measurement

   P. ACQuality (Class):

   r acConfiguration    Enumeration  Describes the physical
                                     configuration of alternating
                                     current as single phase (SNGL),
                                     three-phase delta (DEL), or
                                     three-phase Y (WYE)

   r avgVoltage         Long         The average of the voltage measured
                                     over an integral number of AC
                                     cycles [IEC61850-7-4] 'Vol'

   r avgCurrent         Long         The current per phase
                                     [IEC61850-7-4] 'Amp'

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

   r frequency          Long         Basic frequency of the AC circuit
                                     [IEC61850-7-4] 'Hz'

   r unitMultiplier     Integer      Magnitude of watts for the usage
                                     value in this instance
Top   ToC   RFC7326 - Page 52
   r accuracy           Integer      Percentage value in 100ths
                                     of a percent, representing the
                                     presumed accuracy of active,
                                     reactive, and apparent power
                                     in this instance

   r totalActivePower   Long         A measured value of the actual
                                     power delivered to or consumed by
                                     the load [IEC61850-7-4] 'TotW'

   r totalReactivePower Long         A measured value of the reactive
                                     portion of the apparent power
                                     [IEC61850-7-4] 'TotVAr'

   r totalApparentPower Long         A measured value of the voltage
                                     and current, which determines the
                                     apparent power as the vector sum of
                                     real and reactive power
                                     [IEC61850-7-4] 'TotVA'

   r totalPowerFactor   Long         A measured value of the ratio of
                                     the real power flowing to the load
                                     versus the apparent power
                                     [IEC61850-7-4] 'TotPF'


   Q. DelPhase (Class) inherits from ACQuality:

   r phaseToNext      Long      A measured value of phase to
      PhaseVoltage              next phase voltages where the
                                next phase is [IEC61850-7-4]
                                'PPV'

   r thdVoltage       Long      A calculated value for the
                                voltage Total Harmonic Distortion
                                (THD) for phase to next phase.
                                The method of calculation is not
                                specified [IEC61850-7-4] 'ThdPPV'
Top   ToC   RFC7326 - Page 53
   R. WYEPhase (Class) inherits from ACQuality:

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

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

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

   r avgCurrent      Long   A measured value of phase currents
                            [IEC61850-7-4] 'A'
Top   ToC   RFC7326 - Page 54

Authors' Addresses

John Parello Cisco Systems, Inc. 3550 Cisco Way San Jose, CA 95134 US Phone: +1 408 525 2339 EMail: jparello@cisco.com Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Diegem 1813 BE Phone: +32 2 704 5622 EMail: bclaise@cisco.com Brad Schoening 44 Rivers Edge Drive Little Silver, NJ 07739 US EMail: brad.schoening@verizon.net Juergen Quittek NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 90511 15 EMail: quittek@netlab.nec.de