RFC 7326
Energy Management Framework
Pages: 54
Informational
Informational
Part 2 of 2 – Pages 29 to 54
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
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
}
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,... }
}
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
}
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.
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 +------------+
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 +------------+
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.
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 | +---------------+ | +---------------+ | 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
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
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).
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].
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.
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.
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/>.
[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.
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
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
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"
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
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
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
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'
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'
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