RFC 7326
Energy Management Framework
RFC 7326: Energy Management Framework 🔌✨
okay bestie, welcome to RFC 7326! 🎀 this is part 1 of 10, so grab a snack and get comfy 🍓
The facts first: it's from September 2014 and it's an Informational doc, which means it's published for info and is not a standards-track spec 💅 It's an IETF product, and the authors are J. Parello, B. Claise (both at Cisco Systems, Inc.), B. Schoening (an Independent Consultant), and J. Quittek (NEC Europe Ltd.). The ISSN is 2070-1721. It doesn't list any documents it obsoletes or updates, so it's standing on its own 🦋
Abstract 🌸
okay so this doc sets up a framework for Energy Management (EMAN) for devices and device components that live inside communication networks, or hook up to them 🔌 it gives a physical reference model and an information model. the info model is built around an Energy Management Domain, which is a set of Energy Objects. every Energy Object can be given an identity, a classification, and a context ✨ you can monitor and control Energy Objects for power, Power State, energy, demand, Power Attributes, and battery. it also models the relationships and capabilities between Energy Objects, which is giving very organized 💜
Status of This Memo 🧚
this one is not an Internet Standards Track spec. it's published for informational purposes 🎀
it's a product of the Internet Engineering Task Force (IETF). it represents the consensus of the IETF community, has had public review, and was approved for publication by the Internet Engineering Steering Group (IESG). not every doc the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🙈
for the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7326 🦋
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) as in effect on the date of publication. please read these carefully, because they spell out your rights and restrictions for this document 🫶 any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 💅
Table of Contents 🗺️
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Target Devices ..................................................9
4. Physical Reference Model .......................................10
5. Areas Not Covered by the Framework .............................11
6. Energy Management Abstraction ..................................12
6.1. Conceptual Model ..........................................12
6.2. Energy Object (Class) .....................................13
6.3. Energy Object Attributes ..................................15
6.4. Measurements ..............................................18
6.5. Control ...................................................19
6.6. Relationships .............................................25
7. Energy Management Information Model ............................29
8. Modeling Relationships between Devices .........................33
8.1. Power Source Relationship .................................33
8.2. Metering Relationship .....................................37
8.3. Aggregation Relationship ..................................38
9. Relationship to Other Standards ................................39
10. Security Considerations .......................................39
10.1. Security Considerations for SNMP .........................40
11. IANA Considerations ...........................................41
11.1. IANA Registration of New Power State Sets ................41
11.2. Updating the Registration of Existing Power State Sets ...42
12. References ....................................................43
12.1. Normative References .....................................43
12.2. Informative References ...................................44
13. Acknowledgments ...............................................45
Appendix A. Information Model Listing .............................461. Introduction 🌈
okay so network management is usually split into the five main areas from the ISO Telecommunications Management Network model: Fault, Configuration, Accounting, Performance, and Security Management (FCAPS) [X.700]. the thing is, Energy Management isn't covered by that traditional model, and it's quickly becoming a huge worldwide concern, as [ISO50001] shows 😭
this doc defines an Energy Management framework for devices within, or connected to, communication networks, following the Energy Management requirements in [RFC6988] 🎀 the devices, or their components (like line cards, fans, and disks), can then be monitored and controlled. monitoring covers measuring power, energy, demand, and the attributes of power ⚡ Energy Control happens by setting a device's or component's state 💜 the devices this framework can monitor come in two flavors:
- consumers of energy (like routers and computer systems) and their components (like line cards, fans, and disks) 🖥️
- producers of energy (like an uninterruptible power supply or renewable energy system) and their associated components (like battery cells, inverters, or photovoltaic panels) ☀️
the framework also explains how to identify, classify, and give context to these devices 🧚 context info isn't specific to Energy Management, but the framework does specify some context attributes for these use cases:
- How important is a device in terms of its business impact? 💼
- How should devices be grouped for reporting and searching? 🗂️
- How should a device role be described? 🎭
guidelines for using context in Energy Management are described too ✨
the framework brings in the idea of a Power Interface, which is basically the power version of a network interface 🔥 a Power Interface is an interconnection among devices where energy can be provided, received, or both.
the most basic Energy Management example is one device reporting info about itself 🙈 but a lot of the time, energy isn't measured by the device itself. it gets measured further upstream in the power distribution tree. for example, a Power Distribution Unit (PDU) may measure the energy it supplies to attached devices and report that to an Energy Management System 🍓 so devices often have relationships with other devices or components in the power network. an Energy Management System (EnMS) generally needs to understand the power topology (who provides power to whom), the Metering topology (who meters whom), and the potential Aggregation (who aggregates values from whom) 🧠
the relationships are built on the Power Interface concept 🦋 the different relationships among devices and components specified here include power source, Metering, and Aggregation Relationships.
last thing: the framework does not cover non-electrical equipment, and it doesn't cover energy procurement or manufacturing 🙅♀️ that's it for part 1, bestie! more parts coming 💅💖
2. Terminology ✨
okay bestie, this is the glossary part and I'm lowkey obsessed 🎀. when you see "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc, they mean exactly what RFC 2119 [RFC2119] says they mean 💅.
and the caps part matters!! these words only count as those key words when they're in ALL CAPS. lowercase "should" or "may" is just regular English, not a rule 🙈
some terms also have a NOTE. it's not part of the definition itself, it's just the tea on how different standards orgs word things, or extra clarity 🍓
the terms go in an order where each one can build on the one before it, not alphabetical 🧚. and some terms that are common in electrical engineering or that describe everyday physical stuff are written in lowercase ✨
Energy Management 🌈 Energy Management is a set of functions for measuring, modeling, planning, and optimizing networks so the network and the devices attached to it use energy efficiently and appropriately for what the application needs and what the organization can afford 💖
Reference: Adapted from [TMN].
NOTES:
- "Energy Management" is the whole vibe of activities, methods, procedures, and tools for measuring, modeling, planning, controlling, and optimizing energy use in networked systems [NMF] 🔥
- Energy Management is a management domain that lines up with any of the FCAPS areas 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 bigger Energy Management Policies 💅
Energy Management System (EnMS) 💜 An Energy Management System is a combo of hardware and software used to administer a network, where the main goal is Energy Management ✨
NOTES:
- An Energy Management System according to [ISO50001] (ISO-EnMS) is a set of systems or procedures that let organizations develop and implement an energy policy, set targets and action plans, and account for legal requirements about energy use. An ISO-EnMS helps organizations improve energy performance and show they conform to requirements, standards, and/or legal requirements 👑
- Example ISO-EnMS: Company A has policies and procedures saying there should exist multiple computerized systems that poll energy measurements from their meters and pricing / source data from their local utility. Company A also says their CFO (Chief Financial Officer) should collect information and summarize it quarterly, then send it to an accounting firm to produce carbon accounting reporting as required by their local government 💀
- For the purposes of EMAN, the definition in this doc is the preferred meaning of an EnMS. The definition from [ISO50001] can be called an ISO Energy Management System (ISO-EnMS) 🫶
Energy Monitoring 🦋 Energy Monitoring is a part of Energy Management that's all about collecting or reading information from devices to help with Energy Management 🌸
Energy Control 🌸 Energy Control is a part of Energy Management that's about directing influence over devices 🎀
electrical equipment ⭐ This is a general term for stuff like materials, fittings, devices, appliances, fixtures, apparatus, machines, and so on, that are used as part of, or in connection with, an electric installation 🧚
Reference: [IEEE100].
non-electrical equipment (mechanical equipment) 🍓 This is a general term for the same kinds of things (materials, fittings, devices, appliances, fixtures, apparatus, machines, etc.), but used as part of, or in connection with, non-electrical power installations 🛠️
Reference: Adapted from [IEEE100].
device 🌈 A device is a piece of electrical or non-electrical equipment 💖
Reference: Adapted from [IEEE100].
component 💜 A component is a part of electrical or non-electrical equipment (device) 🫶
Reference: Adapted from [TMN].
power inlet ✨ A power inlet (or simply "inlet") is an interface where a device or component receives energy from another device or component 🔌
power outlet 🔥 A power outlet (or simply "outlet") is an interface where a device or component provides energy to another device or component ⚡
energy 👑 Energy is that which does work or is capable of doing work. As electric utilities use it, it usually refers to electrical energy and is measured in kilowatt-hours (kWh) 💡
Reference: [IEEE100].
NOTE:
- Energy is the capacity of a system to produce external activity or perform work [ISO50001] 🙌
power 🦋 Power is the time rate at which energy is emitted, transferred, or received. It's usually expressed in watts (joules per second) 🌟
Reference: [IEEE100].
demand 🌸 Demand is the average value of power or a related quantity over a specified interval of time. Note: Demand is expressed in kilowatts, kilovolt-amperes, kilovars, or other suitable units 📊
Reference: [IEEE100].
NOTE:
- IEEE100 defines demand using kilo measurements, but for EMAN we use watts with any suitable metric prefix 🧁
provide energy 🎀 A device (or component) "provides" energy to another device if there's an energy flow from this device to the other one 💫
receive energy 🍓 A device (or component) "receives" energy from another device if there's an energy flow from the other device to this one 💫
meter (energy meter) 💜 A meter is a device meant to measure electrical energy by integrating power with respect to time 📏
Reference: Adapted from [IEC60050].
battery 🔋 A battery is one or more cells (an assembly of electrodes, electrolyte, container, terminals, and, usually, separators) that act as a source and/or store of electric energy ⚡
Reference: Adapted from [IEC60050].
Power Interface ✨ A Power Interface is a power inlet, outlet, or both 🔌
Nameplate Power 🌈 The Nameplate Power is the nominal power of a device as the device manufacturer specifies it 🏷️
Power Attributes 🧚 Power Attributes are measurements of the electrical current, voltage, phase, and frequencies at a given point in an electrical power system 📈
Reference: Adapted from [IEC60050].
NOTE:
- Power Attributes don't set any bounds or recommended range for the value. They're just the reading of the value tied to the attribute in question 🙅♀️
Power Quality 🔥 "Power Quality" refers to characteristics of the electrical current, voltage, phase, and frequencies at a given point in an electric power system, judged against a set of reference technical parameters. In some cases these parameters relate to how well the electricity supplied in an electric power system works with the loads connected to it ⚖️
Reference: [IEC60050].
NOTE:
- Electrical characteristics that represent Power Quality information are typically needed by customer facility Energy Management Systems. They aren't meant to cover the detailed requirements of Power Quality monitoring. Standards usually also give ranges of allowed values, but the information attributes are the raw measurements, not the "yes/no" call made by the various standards 🫠
Reference: [ASHRAE-201].
Power State 💖 A Power State is a condition or mode of a device (or component) that broadly describes 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 makes up a named or logical control grouping 🗂️
3. Target Devices 🎯
okay so with Energy Management there's a whole range of devices that might live in the same deployment as a communication network, but they make up 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 that power distribution network 😭
the target devices for Energy Management are all the devices that an Energy Management System (EnMS) can monitor or control, directly or indirectly 💅 these 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 such as middleboxes 🛜
- Components within devices, e.g., a line card inside a switch 🃏
- Batteries functioning 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 (PDUs) 🧰
- Protocol gateway devices for Building Management Systems (BMS) 🏢
- Electrical meters 📏
- Sensor controllers with subtended sensors 🌡️
target devices include devices that talk over the Internet Protocol (IP), and also devices that use other ways to communicate 🫶 the latter get managed through gateways or proxies that can communicate using IP 🌐
4. Physical Reference Model ✨
okay so this section is basically a little picture gallery 🎀 of how the power side of things can be wired up next to the communication side. the authors say there are way more combos possible, but these few basic ones are enough to show how Energy Management setups are different from Network Management setups 💅
quick legend first, bestie: "###" means a transfer of energy ⚡ and "- >" means 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 |
# +------------------+-+
#######| device 3 |
+------------------+
Multiple Power Supplies with Single Device:
+----------------------------------------------+
| Energy Management System |
+----------------------------------------------+
^ ^ ^ ^ ^ ^
mon. | | ctrl. mon. | | ctrl. mon. | | ctrl.
v v v v v v
+----------+ +----------+ +----------+
| power |######| device |######| power |
| source 1 | | | | source 2 |
+----------+ +----------+ +----------+5. Areas Not Covered by the Framework 🙈
okay, real talk: this framework is meant to be a framework for Energy Management in general, but there are some areas it just doesn't cover 🥺
5.1. Non-Electrical Equipment ⚡
the main focus here is electrical equipment 🔌. non-electrical stuff isn't covered, but it could still be modeled if it provides interfaces that follow the framework, like using the same units for power and energy 📏. so anything that doesn't "convert to" or "present as" something equivalent to electrical equipment is simply not addressed 🚫
5.2. Energy Procurement and Manufacturing 🏭
an EnMS can totally be the central hub for corporate reporting, cost math, environmental impact analysis, and regulatory compliance reporting 📊. BUT, energy procurement and the environmental impact of energy use are excluded from Energy Management in this framework 🙅♀️
so the framework does NOT include:
- Cost in currency or environmental units of manufacturing a device 🏗️
- Embedded carbon or environmental equivalences of a device 🌍
- Cost in currency or environmental impact to dismantle or recycle a device ♻️
- Supply chain analysis of energy sources for device deployment 🚚
- Conversion of the usage or production of energy to units expressed from the source of that energy (such as the greenhouse gas emissions associated with the transfer of energy from a diesel source) 🛢️
6. Energy Management Abstraction 🧚
this section is all about a conceptual model of information you can use for Energy Management 📚. each class and category of attributes gets described, with a reason for each one 💡
6.1. Conceptual Model 💜
this part is an information model that deals with Energy Management issues specifically, and it works alongside the existing Network Management models 🤝
so, an info model for Energy Management needs a way to monitor and control devices and components 🎛️. it also needs to describe the relationships between devices and components, and the connections between them 🔗
the model is basically like the one in Network Management: devices, components, and interfaces 🧩. then it layers on extra Energy Management attributes for the stuff that existing Network Management models don't have yet ✨
three classes get used for modeling devices and components, and each has a "(Class)" suffix: Device (Class), Component (Class), and Power Interface (Class) 🎀. all three are sub-types of an abstract Energy Object (Class) 🦋
Summary of Notation for Modeling Physical Equipment
Physical Modeling (Metadata) Model Instance
---------------------------------------------------------
equipment Energy Object (Class) Energy Object
device Device (Class) Device
component Component (Class) Component
inlet/outlet Power Interface (Class) Power Interfacenext up are the attributes of an Energy Object (Class) for identification, classification, context, control, power, and energy 🌈
because the links between devices and components for Energy Management might have nothing to do with the links for Network Management, Energy Object (Classes) get their own separate Relationships (Class) attribute to model those connections 🔀
the following sections go through each class and attribute category in the info model 📖
not every attribute is mandatory for implementations 🤷♀️. specs that describe implementations of this info model in this framework need to be explicit about which attributes are mandatory and which are optional to implement 📝
the formal definitions of the classes and attributes live in Section 7 🗂️
6.2. Energy Object (Class) 🫶
an Energy Object (Class) represents a piece of equipment that's part of, or attached to, a communications network, and that is monitored or controlled, or helps manage another device for Energy Management 🔋
it's an abstract class with the base attributes for representing a piece of equipment for Energy Management 🧸. there are three types: Device (Class), Component (Class), and Power Interface (Class) 👑
6.2.1. Device (Class) 📱
the Device (Class) is a subclass of Energy Object (Class) that represents a physical piece of equipment 🖥️
a Device (Class) instance represents a device that's a consumer, producer, meter, distributor, or store of energy ⚡
a Device (Class) instance may also represent a physical device that holds other components 🧺
6.2.2. Component (Class) 🔧
the Component (Class) is a subclass of Energy Object (Class) that represents a part of a physical piece of equipment 🧩
6.2.3. Power Interface (Class) 🔌
a Power Interface (Class) represents the interconnections (inlet, outlet) among devices or components where energy can be provided, received, or both 💫
the Power Interface (Class) is a subclass of Energy Object (Class) that represents a physical inlet or outlet 🕳️
Power Interfaces have some similarities with network interfaces 👯. a network interface can be in different states, like sending or receiving data on an attached line 📡. likewise, a Power Interface can be receiving or providing energy ⚡
a Power Interface (Class) instance can physically be 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 covers categories of attributes for an Energy Object (Class) 🗃️
6.3.1. Identification 🪪
a Universally Unique Identifier (UUID) [RFC4122] is used to uniquely and persistently identify an Energy Object 🆔
every Energy Object has an optional unique human-readable printable name 💬. possible naming conventions are a textual DNS name, the Media Access Control (MAC) address of the device, the interface ifName, or a text string that uniquely identifies the Energy Object 🏷️. for example, with IP phones, the Energy Object name can be the device's DNS name 📞
on top of that, an alternate key is provided so an Energy Object can optionally be linked with models in different systems 🔑
6.3.2. Context: General 🏢
to help with reporting and to tell Energy Objects apart, each object optionally contains info establishing its business, site, or organizational context within a deployment 🗺️
the Energy Object (Class) has a category attribute that broadly describes how an instance gets used in a deployment 🧾. the category shows whether the Energy Object is mainly functioning as a consumer, producer, meter, distributor, or store of energy 🔋
with 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 how much a device is used or how much it's worth to the site 💎. the range runs from 1 (least important) to 100 (most important) 🌟. the default importance value is 1 🫧
for example, a typical office has several types of phones, which can be rated by their business impact 📞. a public desk phone has a lower importance (for example, 10) than a business-critical emergency phone (for example, 100) 🚨. another example: a company can decide that a PC and a phone for a customer service engineer matter more than a PC and a phone for lobby use 🛋️
EnMS and administrators can set their own ranking 🎛️, but the following 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 hospitality6.3.4. Context: Keywords ✨
okay so the Energy Object (Class) has an attribute for context keywords 🏷️ basically a list of tags you can use to group things, do summary reporting (inside or between Energy Management Domains), and search 🔍 bestie, the examples are giving everything: IT, lobby, HumanResources, Accounting, StoreRoom, CustomerSpace, router, phone, floor2, or SoftwareLab. it's a whole vibe 🌸
how these tags actually get represented is left to the MIB module or other object definition documents that build on this framework 💅 so not this doc's job, lol.
there is no default value for a keyword 🙅♀️ and you can assign multiple keywords to one Energy Object, so stack those tags 🥞
6.3.5. Context: Role 🎀
the Energy Object (Class) has a role attribute 💖 the "role description" string says what the Energy Object's main purpose is in the deployment. it could be any string that describes the job it does there 🧚
how the tag is represented is, again, left to the MIB module or other object definition documents built on this framework. not my problem, bestie 🫶
administrators can define any naming scheme they want for the role 🌈 as a little guidance, a two-word role combining the service the Energy Object provides with its type can be used [IPENERGY]. it's giving organized 📋
some example types of devices: Router, Switch, Light, Phone, WorkStation, Server, Display, Kiosk, HVAC ⚡
here's the service breakdown 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, Billingand a role written as a two-word string looks like this: "Faculty Desktop", "Teller Phone", "Shipping HVAC", "Advertising Display", "Helpdesk Kiosk", "Administration Switch" 💅✨ the vibes are immaculate, honestly.
again, the way this tag is represented is left to the MIB module or other object definition documents based on this framework 🦋
6.3.6. Context: Domain 🌍
the Energy Object (Class) has a string attribute that shows which Energy Management Domain it belongs to 🗺️ 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 💜 that's the main-character move 👑
quick building-management tea ☕ a meter is the one the utility provides for billing and measuring power going to a whole building or a unit inside one. a sub-meter is installed by the customer or user, isn't used by the utility to bill, and is instead used to get measurements from parts of a building 🙈 two different meters, two different jobs, both iconic 💀
the way this tag is represented is left to the MIB module or other object definition documents based on this framework 🌸
an Energy Object MUST be a member of a single Energy Management Domain 🚨 that's why there's only one attribute for it. one domain, no sharing, no cap 🔥
6.4. Measurements 📊
the Energy Object (Class) has attributes that describe power, energy, and demand measurements ⚡
think of it like driving a car 🚗 a speedometer shows how fast your distance is changing (speed), and a power measurement shows the rate energy is transferred. the odometer counts the total distance you've traveled, and an energy measurement shows the energy that's been transferred in total 🛣️ so cute, right?
demand measurements are averages of power measurements over time 🕰️ same car analogy: if you measure your average speed over several time intervals for a given distance, demand is the average power measured over several time intervals for a given energy value 🧁
in this framework, energy is only quantified in watt-hours 💜 physical devices that measure energy in other units have to convert their values to watt-hours, or be represented by Energy Objects that convert to watt-hours. no other units allowed, bestie ✨
6.4.1. Measurements: Power ⚡
the Energy Object (Class) has a Nameplate Power Attribute 🏷️ this describes the nominal power the manufacturer specifies for the device. the EnMS can use Nameplate Power for provisioning, capacity planning, and (potentially) billing 💖
the Energy Object (Class) also has attributes for present power information, plus how that measurement was obtained or derived (for example, actual, estimated, or static) 🔍
a power measurement is qualified with its units, magnitude, and direction of power flow, and also with the means by which it was measured 🎯
power measurement magnitude follows the [IEC61850] definition of unit multiplier for the SI (System International) units of measure 🌈 measured values are represented in SI units, obtained as BaseValue * (10 ^ Scale). for example, if the current power usage of an Energy Object is 17, it could be 17 W, 17 mW, 17 kW, or 17 MW, depending on the scaling factor. 17 W means BaseValue = 17 and Scale = 0, whereas 17 mW means BaseValue = 17 and ScaleFactor = -3 🧮 the math is slaying 💅
an Energy Object (Class) shows how a power measurement was obtained using a caliber and accuracy attribute 🎀 that attribute indicates:
- Whether the measurements were made at the device itself or at a remote source.
- A description of the method used to measure the power, and whether this method can tell actual values apart from estimated ones.
- The accuracy for actual measured values.
6.4.2. Measurements: Power Attributes 🔌
the Energy Object (Class) has an optional attribute for Power Attribute information, which reflects the electrical characteristics of the measurement ⚡ these Power Attributes follow the [IEC61850-7-2] standard for describing AC measurements 🫶
6.4.3. Measurements: Energy 🔋
the Energy Object (Class) has optional attributes that represent energy used, received, produced, and/or stored 💜 typically, only devices or components that can measure actual power will be able to measure energy 🙌
6.4.4. Measurements: Demand 📈
the Energy Object (Class) has optional attributes that represent demand information over time ⏱️ typically, only devices or components that can report actual power are able to measure demand 🌸
6.5. Control 🎮
the Energy Object (Class) has 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 ✨ Power States are typically used for control, but they may be used for monitoring only 👀
a device or component is expected to support at least one set of Power States, made up of at least two states: an on state and an off state 💖
there are lots of existing standards that describe device and component Power States 🌈 this framework supports modeling a mixed set of Power States defined in different standards. a basic example is the three Power States defined in IEEE1621 [IEEE1621]: on, off, and sleep 😴 the Distributed Management Task Force (DMTF) standards organization [DMTF], the Advanced Configuration and Power Interface (ACPI) specification [ACPI], and the Printer Working Group (PWG) all define way more Power States 🖨️ so many options, bestie 🧚
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 an Energy Object uses in a state may be specified by:
- An absolute power value.
- A percentage value of power relative to the Energy Object's Nameplate Power.
- An indication of power relative to another Power State. For example, specify that power in state A is less than in state B.
- 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 📊 the receipts are real 🧾
when requesting that an Energy Object enter a Power State, you can use the Power State's name or number 🎯 optionally, an absolute or percentage of Nameplate Power can be provided so the Energy Object can transition to a nearest or equivalent Power State 🦋
when an Energy Object is set to a particular Power State, the device or component it represents may be busy 😭 the Energy Object should set the desired Power State and then update the actual Power State once the device or component changes 🔄 so there are 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) supports modeling one or multiple Power State Set implementations on the device or component at the same time 🫶
there are currently three Power State Sets specified by IANA 👑
IEEE1621 (256) - [IEEE1621]
DMTF (512) - [DMTF]
EMAN (768) - [RFC7326]the specific states for each Power State Set are in the following sections 📖 the guidelines for changing Power State Sets are in the IANA Considerations section 🧐
6.5.2. Power State Set: IEEE1621 🟢
the IEEE1621 Power State Set [IEEE1621] has three rudimentary states: on, off, or sleep 😴
in IEEE1621, devices are limited to 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] 💜 simple, clean, iconic ✨
6.5.3. Power State Set: DMTF 🖥️
the DMTF [DMTF] standards organization has defined a power profile standard based on the CIM (Common Information Model), which has 15 Power States 🤓
the DMTF standard is aimed at hosts and computers 💻 details about the semantics of each Power State in the DMTF Power State Set can be found in the DMTF Power State Management Profile specification [DMTF] 📚
the DMTF power profile extends ACPI Power States 🧩 here's the mapping between the DMTF and ACPI Power State Sets 🗺️
DMTF ACPI
------------------------------------------------
Reserved (0)
Reserved (1)
ON (2) G0/S0
Sleep-Light (3) G1/S1 G1/S2
Sleep-Deep (4) G1/S3
Power Cycle (Off-Soft) (5) G2/S5
Off-Hard (6) G3
Hibernate (Off-Soft) (7) G1/S4
Off-Soft (8) G2/S5
Power Cycle (Off-Hard) (9) G3
Master Bus Reset (10) G2/S5
Diagnostic Interrupt (11) G2/S5
Off-Soft Graceful (12) G2/S5
Off-Hard Graceful (13) G3
MasterBus Reset Graceful (14) G2/S5
Power Cycle Off-Soft Graceful (15) G2/S5
Power Cycle Off-Hard Graceful (16) G36.5.4. Power State Set: IETF EMAN ✨
okay so the EMAN Power States are basically a glow-up of the basic Power States from [IEEE1621] 💅 and they also pull in the Power States from [ACPI] and [DMTF] 🫶. So on top of the non-operational states from [ACPI] and [DMTF], there are a bunch of intermediate operational states too 🦋.
Physical devices and components are expected to support the EMAN Power State Set, or else they get modeled through an Energy Object that supports these states 🎀.
An Energy Object might implement fewer or more Power States than a particular EMAN Power State Set specifies 🧚. When that happens, the Energy Object can work out its own mapping onto the predefined EMAN Power States in that set 💖.
There are twelve EMAN Power States that expand on [IEEE1621] 🌈. The expanded list is derived from [CISCO-EW] and is split into six operational states and six non-operational states ✨.
The lowest non-operational state is 0, and the highest is 5 😭. Each non-operational state corresponds to an [ACPI] Global and System state between G3 (hard-off) and G1 (sleeping) 🔥. Each operational state represents a performance state and may be mapped to [ACPI] states P0 (maximum performance power) through P5 (minimum performance and minimum power) 💜.
In each of the non-operational states (from mechoff(0) to ready(5)), the Power State before 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 tomechoff(0), but some components remain powered or receive trace power so that the Energy Object can be awakened from its off state. Insoftoff(1), no context is saved, and the device typically requires a complete boot when awakened.hibernate(2): No Energy Object features are available. The Energy Object may be awakened without requiring a complete boot, but the time for availability is longer thansleep(3). An example for statehibernate(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 thanstandby(4). An example for statesleep(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 thanready(5). For example, processor context may not be maintained. Typically, energy consumption is close to zero.ready(5): No Energy Object features are available, except for out-of-band management, such as wake-up mechanisms. This mode is analogous to hot-standby. The Energy Object can be quickly transitioned into an operational state. For example, processors are not executing, but processor context is maintained.lowMinus(6): Indicates that some Energy Object features may not be available and the Energy Object has taken measures or selected options to use less energy thanlow(7).low(7): Indicates that some Energy Object features may not be available and the Energy Object has taken measures or selected options to use less energy thanmediumMinus(8).mediumMinus(8): Indicates that all Energy Object features are available but the Energy Object has taken measures or selected options to use less energy thanmedium(9).medium(9): Indicates that all Energy Object features are available but the Energy Object has taken measures or selected options to use less energy thanhighMinus(10).highMinus(10): Indicates that all Energy Object features are available and the Energy Object has taken measures or selected options to use less energy thanhigh(11).high(11): Indicates that all Energy Object features are available and the Energy Object may use the maximum energy as indicated by the Nameplate Power.
6.5.5. Power State Sets Comparison 🍓
a comparison of Power States from different Power State Sets is laid out in the following tables 💅:
Non-operational states:
IEEE1621 DMTF ACPI EMAN
--------------------------------------------------
off Off-Hard G3/S5 mechoff(0)
off Off-Soft G2/S5 softoff(1)
off Hibernate G1/S4 hibernate(2)
sleep Sleep-Deep G1/S3 sleep(3)
sleep Sleep-Light G1/S2 standby(4)
sleep Sleep-Light G1/S1 ready(5)Operational states:
IEEE1621 DMTF ACPI EMAN
----------------------------------------------------
on on G0/S0/P5 lowMinus(6)
on on G0/S0/P4 low(7)
on on G0/S0/P3 mediumMinus(8)
on on G0/S0/P2 medium(9)
on on G0/S0/P1 highMinus(10)
on on G0/S0/P0 high(11)6.6. Relationships 💜
the Energy Object (Class) holds a set of Relationship (Class) attributes so it can model how devices and components connect to each other 🔗. Two Energy Objects can set up an Energy Object Relationship to show the deployment topology from an Energy Management point of view 🧚.
Relationships are modeled with a Relationship (Class) that holds the UUID of the other participant plus a name describing the type of relationship [CHEN] ✨. There are three types: Power Source, Metering, and Aggregations 🌸.
- A Power Source Relationship is a relationship where one Energy Object provides power to one or more Energy Objects. This gives a view of the physical wiring topology, like a data center server getting power from two specific Power Interfaces on two different PDUs 🔌.
Note: A Power Source Relationship may or may not change as the direction of power changes between two Energy Objects. The relationship may remain to indicate that the change of power direction was unintended or an error condition.
- A Metering Relationship is a relationship where one Energy Object measures power, energy, demand, or Power Attributes of one or more other Energy Objects. This gives the view of the Metering topology. Physical meters can go 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, since meters are connected to the wiring topology. A typical example is meters that clamp onto the existing wiring 🎀.
- An Aggregation Relationship is a relationship where one Energy Object aggregates Energy Management information of one or more other Energy Objects. This gives a model of devices that may aggregate (sum, average, etc.) values for other devices. It's slightly different from the other relationships, since it refers more to a management function 🫶.
In some situations, it isn't possible to discover the Energy Object Relationships, so an EnMS or administrator has to set them manually 🙈. Since relationships can be assigned by hand, the following sections describe guidelines for using them 💖.
6.6.1. Relationship Conventions and Guidelines 📜
this Energy Management framework doesn't impose many "MUST" rules for Energy Object Relationships 🥹. There are always corner cases that can be excluded by making stricter specifications for relationships 🦋. Instead, the framework proposes a series of guidelines, indicated with "SHOULD" and "MAY" 🌈.
6.6.2. Guidelines: Power Source ⚡
Power Source Relationships are meant 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 is for Power Interfaces to take part in Power Source Relationships. In some cases, Energy Objects may not be able to model Power Interfaces, so a Power Source Relationship can be set up between two Energy Objects or two non-connected Power Interfaces 🧚.
Strictly speaking, components and Power Interfaces on the same Device do provide or receive energy from each other. But the Power Source Relationship is meant to show energy transfer between Devices, so the relationship is implied when both are on the same Device ✨.
An Energy Object SHOULD NOT establish a Power Source Relationship with a component 🙅♀️.
- A Power Source Relationship SHOULD be established with the next known Power Interface in the wiring topology.
- The next known Power Interface in the wiring topology is the next device implementing the framework. In some cases, the domain of devices under management may include devices that don't implement the framework. In those 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 🫶.
- Transitive Power Source Relationships SHOULD NOT be established. For example, if Energy Object A has a Power Source Relationship "Poweredby" with Energy Object B, and Energy Object B has a Power Source Relationship "Poweredby" with Energy Object C, then Energy Object A SHOULD NOT have a Power Source Relationship "Poweredby" with Energy Object C 🌸.
6.6.3. Guidelines: Metering Relationship 📏
Metering Relationships are meant 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 in a power distribution system may cover many devices within a wiring topology, this relationship type can be seen as a set 🍓.
Some devices may include hardware that can measure power for components, outlets, or the entire device. For example, some PDUs can measure power for each outlet and are commonly referred to as metered-by-outlet. Others can control power at each power outlet but only measure power at the power inlet, which is commonly referred to as metered-by-device 🔥.
The Metering Relationship could be used to represent a device as metered-by-outlet or metered-by-device, but 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:
- A Metering Relationship MAY be established with any other Energy Object, component, or Power Interface.
- Transitive Metering Relationships MAY be used.
- 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 🧮
Okay bestie, aggregation relationships are for when one device is the one collecting values from other devices 💖 Usually that's energy or power numbers, not stuff inside the same box (like components or Power Interfaces on one device) 🎀
The whole point is to show when one device is giving you aggregate values for a set of other devices, but only when it's not already obvious from the power source or plain containment within a device. No need to restate what's already clear 💅
Setting up aggregation relationships inside the same device would make modeling way more complicated 😭 Plus, the aggregated values can be implied from the power inlets, outlets, and Energy Object values on that same device 🌸
Since an EnMS is naturally an aggregation point ✨, you don't need to model Aggregation for Energy Management Systems.
The Aggregation Relationship is meant for power and energy 🔥 It MAY be used to aggregate other values from the information model, but the rules and whether each attribute can logically be aggregated are out of scope for this document 🦋
In general:
- A Device SHOULD NOT establish an Aggregation Relationship with components contained on the same device.
- A Device SHOULD NOT establish an Aggregation Relationship with the Power Interfaces contained on the same device.
- A Device SHOULD NOT establish an Aggregation Relationship with an EnMS.
- 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 Energy Management framework is based on three relationship types: Aggregation, Metering, and Power Source 💜
It was designed with possible future extensions in mind, new Energy Object Relationships that could show up later ⭐ Here are a couple of examples:
- Some Devices that may not be IP connected could be modeled with a proxy relationship to an Energy Object within the domain 🧚 This type of proxy relationship is left for further development.
- A Power Distribution Unit (PDU) lets devices and components like outlets get "ganged" together as one logical entity for simpler management 👑 That could be modeled with an extension called a "gang relationship", whose semantics would specify the Energy Objects' grouping.
7. Energy Management Information Model 👑
Okay this section is where the concepts from the framework get turned into an information model 🎀 It's a reference for implementers, and it's implemented as MIB modules in the different related IETF EMAN documents. Other programming structures with different data models could be used too 🦋
Data modeling specifications of this information model may, where needed, specify which attributes are required or optional 💅
Here's the UML-to-equivalent-notation cheat sheet, bestie:
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 : typeAnd here's the model itself, the main event 💖
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 walk through examples of how to use the EMAN information model to model physical topologies 🌸 Where it applies, we show how the framework works when devices can be modeled with Power Interfaces 💜 We also show how it works when devices can't be modeled with Power Interfaces and can only be monitored or controlled as a whole 🫶 For instance, a PDU may only be able to measure power and energy for the entire unit, without being able to tell apart its inlets or outlets 😭
8.1. Power Source Relationship ✨
okay so the Power Source Relationship is how we model who is actually feeding power to a device 🔌 It links devices, components, and/or Power Interfaces together so you can see where a device's energy is coming from 💖
we're gonna walk through a few variations of modeling the reference topologies with relationships, bestie 🦋
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:
- Device W inlet 1 is plugged into Device Y outlet 8.
With Power Interfaces:
- Device W has an Energy Object representing the computer itself, as well as one Power Interface defined as an inlet.
- 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:
- Device W has an Energy Object representing the computer.
- 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:
- Device X inlet 1 is plugged into Device Y outlet 8.
- Device X inlet 2 is plugged into Device Y outlet 9.
With Power Interfaces:
- Device X has an Energy Object representing the computer itself. It contains two Power Interfaces defined as inlets.
- 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:
- 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:
- Device X inlet 1 is plugged into Device Y outlet 8.
- Device X inlet 2 is plugged into Device Z outlet 9.
With Power Interfaces:
- Device X has an Energy Object representing the computer itself. It contains two Power Interfaces defined as inlets.
- 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.
- 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:
- 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 📏
okay bestie, a meter in a power distribution system can logically measure the power or energy for all the devices downstream from it 🔥 so a Metering Relationship can be seen as a relationship between a meter and all of those downstream devices 💜
we define it in this case as a Metering Relationship between a meter and the devices downstream from that meter ✨
+-----+---+ meteredBy +--------+ poweredBy +-------+
|Meter| PI|--------------| switch |-------------| phone |
+-----+---+ meters +--------+ powers +-------+
| |
| meteredBy |
+-------------------------------------------+
metersso in cases where the Power Source topology cannot be discovered or derived from the information available in the Energy Management Domain, you can use the Metering topology to relate the upstream meter to the downstream devices, even without specific Power Source Relationships 🦋
a Metering Relationship can happen between devices that aren't directly connected, like this 🌈
+---------------+
| Device 1 |
+---------------+
| PI |
+---------------+
|
+---------------+
| Meter |
+---------------+
.
.
.
meters meters meters
+----------+ +----------+ +-----------+
| Device A | | Device B | | Device C |
+----------+ +----------+ +-----------+and this is kinda like how communications networks model connections between servers (meters) and clients (devices) when the complete Layer 2 topology between them isn't known 🍓
8.3. Aggregation Relationship 🧁
some devices can act as Aggregation points for other devices 💖 for example, a PDU controller device might contain the summation of power and energy readings for many PDU devices, so 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, so it doesn't care how things are wired up 🙈
the functions an Aggregation point may perform include calculating things like average, count, maximum, median, and minimum, or listing (collecting) the Aggregation values, etc. 💅
based on IETF experience gained on Aggregations [RFC7015], the Aggregation function in the EMAN framework is limited to summation ✨ that's it, just adding stuff up 🫶
when Aggregation happens across a set of entities, values to be aggregated may be missing for some of those entities 😭 the EMAN framework does not specify how these should be treated, because 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 scope for the EMAN framework, but the equipment vendor must clearly specify them 🔥
9. Relationship to Other Standards 🌈
this Energy Management framework uses existing standards as much as possible 🫶 especially for information modeling and data modeling [RFC3444] 💜
the data model for power- and energy-related objects is based on [IEC61850] ⭐
specific examples include:
- 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.
- 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.
- The electrical characteristics and quality adhere closely to the [IEC61850-7-4] standard for describing AC measurements. ⚡
- The Power State definitions are based on the DMTF Power State Profile and ACPI models, with operational state extensions. 🧚
10. Security Considerations 🔐✨
Okay bestie, this part is serious, so let's get into it 💅. Some or all of the data attributes specified here may be sensitive or vulnerable in some network environments. Reading or writing them without proper protection, like encryption or access authorization, will hurt network capabilities 😭. Event logs for audit purposes on configuration and other changes should be generated under current authorization, audit, and accounting principles. That helps with investigations, whether the cause is a compromise or a benign misconfiguration, and with any reporting requirements 📋.
The information and control capabilities 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] gives a really good breakdown of threats and mitigations for SNMPv3. You can use it as a guide when implementing this framework with other protocols 🦋.
10.1. Security Considerations for SNMP
Readable objects in MIB modules (meaning objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It's important to control GET and/or NOTIFY access to these objects, and possibly to encrypt their values when they're sent over the network via SNMP 🔒.
Supporting SET operations in a non-secure environment without proper protection can have a negative effect on network operations 💀.
For example:
- Unauthorized changes to the Energy Management Domain or business context of a device will result in misreporting or interruption of power ⚡.
- 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 🔌.
- 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's still no secure control over who on that secure network is allowed to access and GET/SET (read/change/create/delete) the objects in these MIB modules. Main character energy, but make it a security hole 😤.
It is recommended that implementers consider the security features provided by the SNMPv3 framework (see [RFC3411]), including full support for the SNMPv3 cryptographic mechanisms for authentication and confidentiality 🔐.
Deployment of SNMP versions prior to SNMPv3 is not recommended. Instead, it is recommended to deploy SNMPv3 and enable cryptographic security. It's then a customer/operator responsibility to make sure the SNMP entity that gives access to an instance of these MIB modules is properly configured, so access to the objects goes only to those principals (users) who 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], which means review by one of a group of experts designated by an IETF Area Director. The group of experts must check that the requested state is complete and accurate in its description. A purely vendor-specific implementation of a Power State Set shall not be adopted, since that would lead to a 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
As standards evolve, it may become important to deprecate some 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 a clear specification on the deprecation of Power State Sets or Power States registered with IANA. The deprecation or addition shall be administered by IANA through Expert Review [RFC5226], which means 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] entPhysicalUUIDokay bestie, here's the rest of the listing 💅✨
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'Okay bestie, the listing picks up right where we left off, and it's giving classes with measurements 📏✨
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'Okay so the vibe here is "measure everything, label everything" 🔍💅. Totally apparent power is the vector sum of the real and reactive parts, and the power factor is the real power over the apparent power. The DelPhase and WYEPhase classes are both built on top of ACQuality, and each one comes with its own little pile of phase voltages and currents, each tagged with its IEC61850-7-4 name so nobody gets confused 🫶
Authors' Addresses 💌
Here are the four besties who wrote this, with their contact info. Slide into their DMs if you have questions 🦋🌸
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📦 where this page comes from
- ietf: rfc7326 2014-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms