idnits 2.17.1 draft-ietf-eman-framework-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 451 has weird spacing: '...control mon...' == Line 463 has weird spacing: '...control mon...' == Line 2118 has weird spacing: '...ntifier uui...' == Line 2311 has weird spacing: '...eration a mag...' == Line 2358 has weird spacing: '...erState a se...' == (2 more instances...) -- The document date (April 2, 2014) is 3670 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Parello 3 Internet-Draft B. Claise 4 Intended Status: Informational Cisco Systems, Inc. 5 Expires: October 2, 2014 B. Schoening 6 Independent Consultant 7 J. Quittek 8 NEC Europe Ltd 10 April 2, 2014 12 Energy Management Framework 13 draft-ietf-eman-framework-17 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with 18 the provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet 21 Engineering Task Force (IETF), its areas, and its working 22 groups. Note that other groups may also distribute working 23 documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of 26 six months and may be updated, replaced, or obsoleted by 27 other documents at any time. It is inappropriate to use 28 Internet-Drafts as reference material or to cite them other 29 than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be 35 accessed at http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on October 2 2014. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as 42 the document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's 45 Legal Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the 47 date of publication of this document. Please review these 48 documents carefully, as they describe your rights and 49 restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD 51 License text as described in Section 4.e of the Trust Legal 52 Provisions and are provided without warranty as described 53 in the Simplified BSD License. 55 Abstract 57 This document defines a framework for Energy Management for 58 devices and device components within or connected to 59 communication networks. The framework presents a physical 60 reference model and information model. The information 61 model consists of an Energy Management Domain as a set of 62 Energy Objects. Each Energy Object can be attributed with 63 identity, classification, and context. Energy Objects can 64 be monitored and controlled with respect to power, Power 65 State, energy, demand, Power Attributes, and battery. 66 Additionally the framework models relationships and 67 capabilities between Energy Objects. 69 Table of Contents 71 1. Introduction .............................................. 3 72 2. Terminology ............................................... 4 73 3. Target Devices ........................................... 10 74 4. Physical Reference Model ................................. 11 75 5. Not Covered by the Framework ............................. 12 76 6. Energy Management Abstraction ............................ 13 77 6.1. Conceptual Model .................................... 13 78 6.2. Energy Object (Class) ............................... 14 79 6.3. Energy Object Attributes ............................ 15 80 6.4. Measurements ........................................ 18 81 6.5. Control ............................................. 20 82 6.6. Relationships ....................................... 26 83 7. Energy Management Information Model ...................... 30 84 8. Modeling Relationships between Devices ................... 34 85 8.1. Power Source Relationship ........................... 34 86 8.2. Metering Relationship ............................... 38 87 8.3. Aggregation Relationship ............................ 39 88 9. Relationship to Other Standards .......................... 40 89 10. Implementation Status ................................... 40 90 11. Security Considerations ................................. 41 91 11.1. Security Considerations for SNMP ................... 41 92 12. IANA Considerations...................................... 42 93 12.1. IANA Registration of new Power State Sets .......... 42 94 12.2. Updating the Registration of Existing Power State 95 Sets ..................................................... 44 96 13. References .............................................. 44 97 14. Acknowledgments ......................................... 47 98 Appendix A. Information Model Listing ....................... 47 99 Authors' Addresses .......................................... 57 101 1. Introduction 103 Network management is often divided into the five main 104 areas defined in the ISO Telecommunications Management 105 Network model: Fault, Configuration, Accounting, 106 Performance, and Security Management (FCAPS) [X.700]. Not 107 covered by this traditional management model is Energy 108 Management, which is rapidly becoming a critical area of 109 concern worldwide, as seen in [ISO50001]. 111 This document defines an Energy Management framework for 112 the Energy Management requirements specified in [RFC6988]. 113 The devices or components of these devices (such as line 114 cards, fans, and disks) can then be monitored and 115 controlled. Monitoring includes measuring power, energy, 116 demand, and attributes of power. Energy control can be 117 performed by setting a devices' or components' state. The 118 framework also covers monitoring and control of batteries 119 contained in devices. 121 This framework further describes how to identify, classify 122 and provide context for such devices. While context 123 information is not specific to Energy Management, some 124 context attributes are specified in the framework, 125 addressing the following use cases: how important is a 126 device in terms of its business impact, how should devices 127 be grouped for reporting and searching, and how should a 128 device role be described. Guidelines for using context for 129 Energy Management are described. 131 The framework introduces the concept of a Power Interface 132 that is analogous to a network interface. A Power Interface 133 is defined as an interconnection among devices where energy 134 can be provided, received, or both. 136 The most basic example of Energy Management is a single 137 device reporting information about itself. In many cases, 138 however, energy is not measured by the device itself, but 139 measured upstream in the power distribution tree. For 140 example, a power distribution unit (PDU) may measure the 141 energy it supplies to attached devices and report this to 142 an energy management system. Therefore, devices often have 143 relationships to other devices or components in the power 144 network. An EnMS (Energy Management System) generally 145 requires an understanding of the power topology (who 146 provides power to whom), the metering topology (who meters 147 whom), and an understanding of the potential aggregation 148 (who aggregates values of others). 150 The relationships build on the Power Interface concept. The 151 different relationships among devices and components, 152 specified in this document, include: power source, 153 metering, and aggregation relationships. 155 The framework does not cover non-electrical equipment nor 156 does it cover energy procurement and manufacturing. 158 2. Terminology 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 161 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 162 and "OPTIONAL" in this document are to be interpreted as 163 described in RFC-2119 [RFC2119]. 165 In this document these words will appear with that 166 interpretation only when in ALL CAPS. Lower case uses of 167 these words are not to be interpreted as carrying RFC-2119 168 significance. 170 In this section some terms have a NOTE that is not part of 171 the definition itself, but accounts for differences between 172 terminologies of different standards organizations or 173 further clarifies the definition. 175 The terms are listing in an order that aids in reading 176 where terms may build off a previous term as opposed to an 177 alphabetical ordering. Some terms that are common in 178 electrical engineering or that describe common physical 179 items use a lower case notation. 181 Energy Management 182 Energy Management is a set of functions for measuring, 183 modeling, planning, and optimizing networks to ensure 184 that the network and network attached devices use energy 185 efficiently and appropriately for the nature of the 186 application and the cost constraints of the organization. 188 Reference: Adapted from [ITU-T-M-3400] 190 NOTES: 191 1. Energy Management refers to the activities, methods, 192 procedures and tools that pertain to measuring, modeling, 193 planning, controlling and optimizing the use of energy in 194 networked systems [NMF]. 196 2. Energy Management is a management domain which is 197 congruent to any of the FCAPS areas of management in the 198 ISO/OSI Network Management Model [TMN]. Energy Management 199 for communication networks and attached devices is a 200 subset or part of an organization's greater Energy 201 Management Policies. 203 Energy Management System (EnMS) 204 An Energy Management System is a combination of hardware 205 and software used to administer a network with the 206 primary purpose of energy management. 208 NOTES: 209 1. An Energy Management System according to [ISO50001] 210 (ISO-EnMS) is a set of systems or procedures upon which 211 organizations can develop and implement an energy policy, 212 set targets, action plans and take into account legal 213 requirements related to energy use. An ISO-EnMS allows 214 organizations to improve energy performance and 215 demonstrate conformity to requirements, standards, and/or 216 legal requirements. 218 2. Example ISO-EnMS: Company A defines a set of policies 219 and procedures indicating there should exist multiple 220 computerized systems that will poll energy measurements 221 from their meters and pricing / source data from their 222 local utility. Company A specifies that their CFO (Chief 223 Financial Officer) should collect information and 224 summarize it quarterly to be sent to an accounting firm 225 to produce carbon accounting reporting as required by 226 their local government. 228 3. For the purposes of EMAN, the definition herein is the 229 preferred meaning of an Energy Management System (EnMS). 230 The definition from [ISO50001] can be referred to as ISO 231 Energy Management System (ISO-EnMS). 233 Energy Monitoring 234 Energy Monitoring is a part of Energy Management that 235 deals with collecting or reading information from devices 236 to aid in Energy Management. 238 Energy Control 239 Energy Control is a part of Energy Management that deals 240 with directing influence over devices. 242 electrical equipment 243 A general term including materials, fittings, devices, 244 appliances, fixtures, apparatus, machines, etc., used as 245 a part of, or in connection with, an electric 246 installation. 247 Reference: [IEEE100] 249 non-electrical equipment (mechanical equipment) 250 A general term including materials, fittings, devices, 251 appliances, fixtures, apparatus, machines, etc., used as 252 a part of, or in connection with, non-electrical power 253 installations. 255 Reference: Adapted from [IEEE100] 257 device 258 A piece of electrical or non-electrical equipment. 260 Reference: Adapted from [IEEE100] 262 component 263 A part of an electrical or non-electrical equipment 264 (device). 266 Reference: Adapted from [ITU-T-M-3400] 268 power inlet 269 A power inlet (or simply inlet) is an interface at which 270 a device or component receives energy from another device 271 or component. 273 power outlet 274 A power outlet (or simply outlet) is an interface at 275 which a device or component provides energy to another 276 device or component. 278 energy 279 That which does work or is capable of doing work. As used 280 by electric utilities, it is generally a reference to 281 electrical energy and is measured in kilowatt hours 282 (kWh). 284 Reference: [IEEE100] 286 NOTES 287 1. Energy is the capacity of a system to produce external 288 activity or perform work [ISO50001] 290 power 291 The time rate at which energy is emitted, transferred, or 292 received; usually expressed in watts (joules per second). 294 Reference: [IEEE100] 296 demand 297 The average value of power or a related quantity over a 298 specified interval of time. Note: Demand is expressed in 299 kilowatts, kilovolt-amperes, kilovars, or other suitable 300 units. 302 Reference: [IEEE100] 304 NOTES: 305 1. While IEEE100 defines demand in kilo measurements, for 306 EMAN we use watts with any suitable metric prefix. 308 provide energy 309 A device (or component) "provides" energy to another 310 device if there is an energy flow from this device to the 311 other one. 313 receive energy 314 A device (or component) "receives" energy from another 315 device if there is an energy flow from the other device 316 to this one. 318 meter (energy meter) 319 a device intended to measure electrical energy by 320 integrating power with respect to time. 322 Reference: Adapted from [IEC60050] 324 battery 325 one or more cells (consisting of an assembly of 326 electrodes, electrolyte, container, terminals and usually 327 separators) that are a source and/or store of electric 328 energy. 330 Reference: Adapted from [IEC60050] 332 Power Interface 333 A power inlet, outlet, or both. 335 Nameplate Power 336 The Nameplate Power is the nominal power of a device as 337 specified by the device manufacturer. 339 Power Attributes 340 Measurements of the electrical current, voltage, phase 341 and frequencies at a given point in an electrical power 342 system. 343 Reference: Adapted from [IEC60050] 345 NOTES: 346 1. Power Attributes are not intended to provide a 347 judgment with respect to a reference or technical value 348 and are independent of any usage context. 350 Power Quality 351 Characteristics of the electrical current, voltage, phase 352 and frequencies at a given point in an electric power 353 system, evaluated against a set of reference technical 354 parameters. These parameters might, in some cases, relate 355 to the compatibility between electricity supplied in an 356 electric power system and the loads connected to that 357 electric power system. 359 Reference: [IEC60050] 360 NOTES: 361 1. Electrical characteristics representing power quality 362 information are typically required by customer facility 363 energy management systems. It is not intended to satisfy 364 the detailed requirements of power quality monitoring. 365 Standards typically also give ranges of allowed values; 366 the information attributes are the raw measurements, not 367 the "yes/no" determination by the various standards. 369 Reference: [ASHRAE-201] 371 Power State 372 A Power State is a condition or mode of a device (or 373 component) that broadly characterizes its capabilities, 374 power, and responsiveness to input. 376 Reference: Adapted from [IEEE1621] 378 Power State Set 379 A Power State Set is a collection of Power States that 380 comprises a named or logical control grouping. 382 3. Target Devices 384 With Energy Management, there exists a wide variety of 385 devices that may be contained in the same deployment as a 386 communication network but comprise a separate facility, 387 home, or power distribution network. 389 Energy Management has special challenges because a power 390 distribution network supplies energy to devices and 391 components, while a separate communications network 392 monitors and controls the power distribution network. 394 The target devices for Energy Management are all devices 395 that can be monitored or controlled (directly or 396 indirectly) by an Energy Management System (EnMS). These 397 target devices include, for example: 398 . Simple electrical appliances and fixtures 399 . Hosts, such as a PC, a server, or a printer 400 . Switches, routers, base stations, and other network 401 equipment and middle boxes 402 . Components within devices, a line card inside a 403 switch 404 . Batteries as a device or component that is a store 405 of energy 406 . Devices or components that charge or produce energy 407 such as solar cells, charging stations or 408 generators 409 . Power over Ethernet (PoE) endpoints 410 . Power Distribution Units (PDU) 411 . Protocol gateway devices for Building Management 412 Systems (BMS) 413 . Electrical meters 414 . Sensor controllers with subtended sensors 416 Target devices include devices that communicate via the 417 Internet Protocol (IP) as well as devices using other means 418 for communication. The latter are managed through gateways 419 or proxies that can communicate using IP. 421 4. Physical Reference Model 423 The following reference model describes physical power 424 topologies that exist in parallel to a communication 425 topology. While many more topologies can be created with 426 combination of devices, the following are some basic ones 427 that show how Energy Management topologies differ from 428 Network Management topologies. 430 NOTE: "###" is used to denote a transfer of energy. 431 - > is used to denote a transfer of information. 433 Basic Energy Management 435 +--------------------------+ 436 | Energy Management System | 437 +--------------------------+ 438 ^ ^ 439 monitoring | | control 440 v v 441 +---------+ 442 | device | 443 +---------+ 445 Basic Power Supply 447 +-----------------------------------------+ 448 | Energy Management System | 449 +-----------------------------------------+ 450 ^ ^ ^ ^ 451 monitoring | | control monitoring | | control 452 v v v v 453 +--------------+ +-----------------+ 454 | power source |########| device | 455 +--------------+ +-----------------+ 457 Single Power Supply with Multiple Devices 459 +---------------------------------------+ 460 | Energy Management System | 461 +---------------------------------------+ 462 ^ ^ ^ ^ 463 monitoring | | control monitoring | | control 464 v v v v 465 +--------+ +------------------+ 466 | power |########| device 1 | 467 | source | # +------------------+-+ 468 +--------+ #######| device 2 | 469 # +------------------+-+ 470 #######| device 3 | 471 +------------------+ 473 Multiple Power Supplies with Single Devices 475 +----------------------------------------------+ 476 | Energy Management System | 477 +----------------------------------------------+ 478 ^ ^ ^ ^ ^ ^ 479 mon. | | ctrl. mon. | | ctrl. mon. | | ctrl. 480 v v v v v v 481 +----------+ +----------+ +----------+ 482 | power |######| device |######| power | 483 | source 1 | | | | source 2 | 484 +----------+ +----------+ +----------+ 486 5. Not Covered by the Framework 488 While this framework is intended as a framework for Energy 489 Management in general, there are some areas that are not 490 covered. 492 Non-Electrical Equipment 494 The primary focus of this framework is the management of 495 electrical equipment. Non-Electrical equipment, not covered 496 in this framework, could nevertheless be modeled by 497 providing interfaces that comply with the framework: for 498 example, using the same units for power and energy. 499 Therefore, non-electrical equipment that do not convert-to 500 or present-as equivalent to electrical equipment are not 501 addressed. 503 Energy Procurement and Manufacturing 505 While an EnMS may be a central point for corporate 506 reporting, cost computation, environmental impact analysis, 507 and regulatory compliance reporting - Energy Management in 508 this framework excludes energy procurement and the 509 environmental impact of energy use. 511 As such the framework does not include: 512 o Cost in currency or environmental units of 513 manufacturing a device. 514 o Embedded carbon or environmental equivalences of a 515 device 517 o Cost in currency or environmental impact to dismantle 518 or recycle a device. 519 o Supply chain analysis of energy sources for device 520 deployment 521 o Conversion of the usage or production of energy to 522 units expressed from the source of that energy (such 523 as the greenhouse gas emissions associated the 524 transfer of energy from a diesel source). 526 6. Energy Management Abstraction 528 This section describes a conceptual model of information 529 that can be used for Energy Management. The classes and 530 categories of attributes in the model are described with 531 rationale for each. 533 6.1. Conceptual Model 535 This section describes an information model that addresses 536 issues specific to Energy Management, which complements 537 existing Network Management models. 539 An information model for Energy Management will need to 540 describe a means to monitor and control devices and 541 components. The model will also need to describe the 542 relationships among and connections between devices and 543 components. 545 This section defines a similar conceptual model for devices 546 and components to that used in Network Management: devices, 547 components, and interfaces. This section then defines the 548 additional attributes specific to Energy Management for 549 those entities that are not available in existing Network 550 Management models. 552 For modeling the devices and components this section 553 describes three classes denoted by a "(Class)" suffix: a 554 Device (Class), a Component (Class), and a Power Interface 555 (Class). These classes are sub-types of an abstract Energy 556 Object (Class). 558 Summary of Notation for Modeling Physical Equipment 560 Physical Modeling (Meta Data) Model Instance 561 --------------------------------------------------------- 562 equipment Energy Object (Class) Energy Object 563 device Device (Class) Device 564 component Component (Class) Component 565 inlet / outlet Power Interface (Class) Power Interface 566 This section then describes the attributes of an Energy 567 Object (Class) for identification, classification, context, 568 control, power and energy. 570 Since the interconnections between devices and components 571 for Energy Management may have no relation to the 572 interconnections for Network Management the Energy Object 573 (Classes) contain a separate Relationships (Class) as an 574 attribute to model these types of interconnections. 576 The next sections describe the each of the classes and 577 categories of attributes in the information model. 579 Not all of the attributes are mandatory for 580 implementations. Specifications describing implementations 581 of the information model in this framework need to be 582 explicit about which are mandatory and which are optional 583 to implement 585 The formal definitions of the classes and attributes are 586 specified in Section 7. 588 6.2. Energy Object (Class) 590 An Energy Object (Class) represents a piece of equipment 591 that is part of, or attached to, a communications network 592 which is monitored, controlled, or aids in the management 593 of another device for Energy Management. 595 The Energy Object (Class) is an abstract class that 596 contains the base attributes to represent a piece of 597 equipment for Energy Management. There are three types of 598 Energy Object (Class): Device (Class), Component (Class) 599 and Power Interface (Class). 601 6.2.1. Device (Class) 603 The Device (Class) is a sub-class of Energy Object (Class) 604 that represents a physical piece of equipment. 606 A Device (Class) instance represents a device that is a 607 consumer, producer, meter, distributor, or store of energy. 609 A Device (Class) instance may represent a physical device 610 that contains other components. 612 6.2.2. Component (Class) 614 The Component (Class) is a sub-class of Energy Object 615 (Class) that represents a part of a physical piece of 616 equipment. 618 6.2.3. Power Interface (Class) 620 A Power Interface (Class) represents the interconnections 621 (inlet, outlet) among devices or components where energy 622 can be provided, received, or both. 624 The Power Interface (Class) is a sub-class of Energy Object 625 (Class) that represents a physical inlet or outlet. 627 There are some similarities between Power Interfaces and 628 network interfaces. A network interface can be set to 629 different states, such as sending or receiving data on an 630 attached line. Similarly, a Power Interface can be 631 receiving or providing energy. 633 A Power Interface (Class) instance can represent 634 (physically) an AC power socket, an AC power cord attached 635 to a device, or an 8P8C (RJ45) PoE socket, etc. 637 6.3. Energy Object Attributes 639 This section describes categories of attributes for an 640 Energy Object (Class). 642 6.3.1. Identification 644 A Universal Unique Identifier (UUID) [RFC4122] is used to 645 uniquely and persistently identify an Energy Object. 647 Every Energy Object has an optional unique human readable 648 printable name. Possible naming conventions are: textual 649 DNS name, MAC address of the device, interface ifName, or a 650 text string uniquely identifying the Energy Object. As an 651 example, in the case of IP phones, the Energy Object name 652 can be the device's DNS name. 654 Additionally an alternate key is provided to allow an 655 Energy Object to be optionally linked with models in 656 different systems. 658 6.3.2. Context: General 659 In order to aid in reporting and in differentiation between 660 Energy Objects, each object optionally contains information 661 establishing its business, site, or organizational context 662 within a deployment. 664 The Energy Object (Class) contains a category attribute 665 that broadly describes how an instance is used in a 666 deployment. The category indicates if the Energy Object is 667 primarily functioning as a consumer, producer, meter, 668 distributor or store of energy. 670 Given the category and context of an object, an EnMS can 671 summarize or analyze measurements for the site. 673 6.3.3. Context: Importance 675 An Energy Object can provide an importance value in the 676 range of 1 to 100 to help rank a device's use or relative 677 value to the site. The importance range is from 1 (least 678 important) to 100 (most important). The default importance 679 value is 1. 681 For example: A typical office environment has several types 682 of phones, which can be rated according to their business 683 impact. A public desk phone has a lower importance (for 684 example, 10) than a business-critical emergency phone (for 685 example, 100). As another example: A company can consider 686 that a PC and a phone for a customer-service engineer are 687 more important than a PC and a phone for lobby use. 689 Although EnMS and administrators can establish their own 690 ranking, the following example is a broad recommendation 691 for commercial deployments [CISCO-EW]: 693 90 to 100 Emergency response 694 80 to 90 Executive or business-critical 695 70 to 79 General or Average 696 60 to 69 Staff or support 697 40 to 59 Public or guest 698 1 to 39 Decorative or hospitality 700 6.3.4. Context: Keywords 702 The Energy Object (Class) contains an attribute with 703 context keywords. 705 An Energy Object can provide a set of keywords that are a 706 list of tags that can be used for grouping, for summary 707 reporting (within or between Energy Management Domains), 708 and for searching. 710 All alphanumeric characters and symbols (other than a 711 comma), such as #, (, $, !, and &, are allowed. 712 Alphanumeric and symbol characters from the entire Unicode 713 repertoire are expected to be reasonable. Potential 714 examples are: IT, lobby, HumanResources, Accounting, 715 StoreRoom, CustomerSpace, router, phone, floor2, or 716 SoftwareLab. 718 There is no default value for a keyword. Multiple keywords 719 can be assigned to an Energy Object. White spaces before 720 and after the commas are excluded, as well as within a 721 keyword itself. In such cases, commas separate the keywords 722 and no spaces between keywords are allowed. For example, 723 "HR,Bldg1,Private". 725 6.3.5. Context: Role 727 The Energy Object (Class) contains a role attribute. The 728 "role description" string indicates the primary purpose the 729 Energy Object serves in the deployment. This could be a 730 string representing the purpose the Energy Object fulfills 731 in the deployment. 733 Administrators can define any naming scheme for the role. 734 As guidance, a two-word role that combines the service the 735 Energy Object provides along with type can be used 736 [IPENERGY]. 738 Example types of devices: Router, Switch, Light, Phone, 739 WorkStation, Server, Display, Kiosk, HVAC. 741 Example Services by Line of Business: 743 Line of Business Service 744 ----------------------------------------------------- 745 Education Student, Faculty, 746 Administration, 747 Athletic 748 Finance Trader, Teller, Fulfillment 749 Manufacturing Assembly, Control, Shipping 750 Retail Advertising, Cashier 751 Support Helpdesk, Management 752 Medical Patient, Administration, Billing 754 Role as a two-word string: "Faculty Desktop", "Teller 755 Phone", "Shipping HVAC", "Advertising Display", "Helpdesk 756 Kiosk", "Administration Switch". 758 6.3.6. Context: Domain 760 The Energy Object (Class) contains a string attribute to 761 indicate membership in an Energy Management Domain. An 762 Energy Management Domain can be any collection of Energy 763 Objects in a deployment, but it is recommended to map 1:1 764 with a metered or sub-metered portion of the site. 766 In building management, a meter refers to the meter 767 provided by the utility used for billing and measuring 768 power to an entire building or unit within a building. A 769 sub-meter refers to a customer- or user-installed meter 770 that is not used by the utility to bill but is instead used 771 to get measurements from sub portions of a building. 773 An Energy Object MUST be a member of a single Energy 774 Management Domain therefore one attribute is provided. 776 6.4. Measurements 778 The Energy Object (Class) contains attributes to describe 779 power, energy and demand measurements. 781 An analogy for understanding power versus energy 782 measurements can be made to speed and distance in 783 automobiles. Just as a speedometer indicates the rate of 784 change of distance (speed), a power measurement indicates 785 the rate of transfer of energy. The odometer in an 786 automobile measures the cumulative distance traveled and 787 similarly an energy measurement indicates the accumulated 788 energy transferred. 790 Demand measurements are averages of power measurements over 791 time. So using the same analogy to an automobile: measuring 792 the average vehicle speed over multiple intervals of time 793 for a given distance travelled, demand is the average power 794 measured over multiple time intervals for a given energy 795 value. 797 Within this framework, energy will only be quantified in 798 units of watt-hours. Physical devices measuring energy in 799 other units must convert values to watt-hours or be 800 represented by Energy Objects that convert to watt-hours. 802 6.4.1. Measurements: Power 804 The Energy Object (Class) contains a Nameplate Power 805 attribute that describes the nominal power as specified by 806 the manufacturer of the device. The EnMS can use the 807 Nameplate Power for provisioning, capacity planning and 808 (potentially) billing. 810 The Energy Object (Class) has attributes that describe the 811 present power information, along with how that measurement 812 was obtained or derived (e.g., actual, estimated, or 813 static). 815 A power measurement is qualified with the units, magnitude 816 and direction of power flow, and is qualified as to the 817 means by which the measurement was made. 819 Power measurement magnitude conforms to the [IEC61850] 820 definition of unit multiplier for the SI (System 821 International) units of measure. Measured values are 822 represented in SI units obtained by BaseValue * (10 ^ 823 Scale). For example, if current power usage of an Energy 824 Object is 17, it could be 17 W, 17 mW, 17 kW, or 17 mW, 825 depending on the value of the scaling factor. 17 W implies 826 that the BaseValue is 17 and Scale = 0, whereas 17 mW 827 implies BaseValue = 17 and ScaleFactor = -3. 829 An Energy Object (Class) indicates how the power 830 measurement was obtained with a caliber and accuracy 831 attribute that indicates: 832 o Whether the measurements were made at the device 833 itself or at a remote source. 834 o Description of the method that was used to measure 835 the power and whether this method can distinguish 836 actual or estimated values. 837 o Accuracy for actual measured values 839 6.4.2. Measurements: Power Attributes 841 The Energy Object (Class) contains an optional attribute 842 that describes Power Attribute information reflecting the 843 electrical characteristics of the measurement. These Power 844 Attributes adhere to the [IEC61850-7-2] standard for 845 describing AC measurements. 847 6.4.3. Measurements: Energy 849 The Energy Object (Class) contains optional attributes that 850 represent the energy used, received, produced and or 851 stored. Typically only devices or components that can 852 measure actual power will have the ability to measure 853 energy. 855 6.4.4. Measurements: Demand 857 The Energy Object (Class) contains optional attributes that 858 represent demand information over time. Typically only 859 devices or components that can report actual power are 860 capable of measuring demand. 862 6.5. Control 864 The Energy Object (Class) contains a Power State Set 865 (Class) attribute that represents the set of Power States a 866 device or component supports. 868 A Power State describes a condition or mode of a device or 869 component. While Power States are typically used for 870 control they may be used for monitoring only. 872 A device or component is expected to support at least one 873 set of Power States consisting of at least two states, an 874 on state and an off state. 876 There are many existing standards describing device and 877 component Power States. The framework supports modeling a 878 mixed set of Power States defined in different standards. A 879 basic example is given by the three Power States defined in 880 IEEE1621 [IEEE1621]: on, off, and sleep. The DMTF [DMTF], 881 ACPI [ACPI], and Printer Working Group (PWG) all define 882 larger numbers of Power States. 884 The semantics of a Power State are specified by 885 a) the functionality provided by an Energy Object in 886 this state, 887 b) a limitation of the power that an Energy Object uses 888 in this state, 889 c) a combination of a) and b) 891 The semantics of a Power State should be clearly defined. 892 Limitation (curtailment) of the power used by an Energy 893 Object in a state may be specified by: 894 o an absolute power value 895 o a percentage value of power relative to the energy 896 object's nameplate power 898 o an indication of power relative to another power 899 state. For example: Specify that power in state A is 900 less than in state B. 901 o For supporting Power State management an Energy 902 Object provides statistics on Power States including 903 the time an Energy Object spent in a certain Power 904 State and the number of times an Energy Object 905 entered a power state. 907 When requesting an Energy Object to enter a Power State an 908 indication of the Power State's name or number can be used. 909 Optionally an absolute or percentage of Nameplate Power can 910 be provided to allow the Energy Object to transition to a 911 nearest or equivalent Power State. 913 When an Energy Object is set to a particular Power State, 914 the represented device or component may be busy. The Energy 915 Object should set the desired Power State and then update 916 the actual Power State when the device or component 917 changes. There are then two Power State (Class) control 918 attributes: actual and requested. 920 The following sections describe well-known Power States for 921 devices and components that should be modeled in the 922 information model. 924 6.5.1. Power State Sets 926 There are several standards and implementations of Power 927 State Sets. The Energy Object (Class) support modeling one 928 or multiple Power State Set implementation(s) on the device 929 or component concurrently. 931 There are currently three Power State Sets advocated: 932 IEEE1621(256) - [IEEE1621] 933 DMTF(512) - [DMTF] 934 EMAN(768) - [this document] 936 The respective specific states related to each Power State 937 Set are specified in the following sections. The guidelines 938 for the modification of Power State Sets are specified in 939 the IANA Considerations Section. 941 6.5.2. Power State Set: IEEE1621 943 The IEEE1621 Power State Set [IEEE1621] consists of 3 944 rudimentary states: on, off or sleep. 946 In IEEE1621 devices are limited to the three basic power 947 states - on (2), sleep (1), and off (0). Any additional 948 power states are variants of one of the basic states rather 949 than a fourth state [IEEE1621]. 951 6.5.3. Power State Set: DMTF 953 The DMTF [DMTF] standards organization has defined a power 954 profile standard based on the CIM (Common Information 955 Model) model that consists of 15 power states: 957 {ON (2), SleepLight (3), SleepDeep (4), Off-Hard (5), Off- 958 Soft (6), Hibernate(7), PowerCycle Off-Soft (8), PowerCycle 959 Off-Hard (9), MasterBus reset (10), Diagnostic Interrupt 960 (11), Off-Soft-Graceful (12), Off-Hard Graceful (13), 961 MasterBus reset Graceful (14), Power-Cycle Off-Soft 962 Graceful (15), PowerCycle-Hard Graceful (16)} 964 The DMTF standard is targeted for hosts and computers. 965 Details of the semantics of each Power State within the 966 DMTF Power State Set can be obtained from the DMTF Power 967 State Management Profile specification [DMTF]. 969 The DMTF power profile extends ACPI power states. The 970 following table provides a mapping between DMTF and ACPI 971 Power State Set: 973 DMTF ACPI 974 Reserved (0) 975 Reserved (1) 976 ON (2) G0-S0 977 Sleep-Light (3) G1-S1 G1-S2 978 Sleep-Deep (4) G1-S3 979 Power Cycle (Off-Soft) (5) G2-S5 980 Off-hard (6) G3 981 Hibernate (Off-Soft) (7) G1-S4 982 Off-Soft (8) G2-S5 983 Power Cycle (Off-Hard) (9) G3 984 Master Bus Reset (10) G2-S5 985 Diagnostic Interrupt (11) G2-S5 986 Off-Soft Graceful (12) G2-S5 987 Off-Hard Graceful (13) G3 988 MasterBus Reset Graceful (14) G2-S5 989 Power Cycle off-soft Graceful (15) G2-S5 990 Power Cycle off-hard Graceful (16) G3 992 6.5.4. Power State Set: IETF EMAN 993 The EMAN Power States are an expansion of the basic Power 994 States as defined in [IEEE1621] that also incorporates the 995 Power States defined in [ACPI] and [DMTF]. Therefore, in 996 addition to the non-operational states as defined in [ACPI] 997 and [DMTF] standards, several intermediate operational 998 states have been defined. 1000 Physical devices and components are expected to support the 1001 EMAN Power State Set or to be modeled via an Energy Object 1002 the supports these states. 1004 An Energy Object may implement fewer or more Power States 1005 than a particular EMAN Power State Set specifies. In that 1006 case, the Energy Object implementation can determine its 1007 own mapping to the predefined EMAN Power States within the 1008 EMAN Power State Set. 1010 There are twelve EMAN Power States that expand on 1011 [IEEE1621]. The expanded list of Power States is derived 1012 from [CISCO-EW] and is divided into six operational states 1013 and six non-operational states. 1015 The lowest non-operational state is 1 and the highest is 6. 1016 Each non-operational state corresponds to an [ACPI] Global 1017 and System state between G3 (hard-off) and G1 (sleeping). 1018 Each operational state represents a performance state, and 1019 may be mapped to [ACPI] states P0 (maximum performance 1020 power) through P5 (minimum performance and minimum power). 1022 In each of the non-operational states (from mechoff(0) to 1023 ready(5)), the Power State preceding it is expected to have 1024 a lower Power value and a longer delay in returning to an 1025 operational state: 1027 mechoff(0) : An off state where no Energy Object 1028 features are available. The Energy Object is unavailable. 1029 No energy is being consumed and the power connector can be 1030 removed. 1032 softoff(1) : Similar to mechoff(0), but some 1033 components remain powered or receive trace power so that 1034 the Energy Object can be awakened from its off state. In 1035 softoff(1), no context is saved and the device typically 1036 requires a complete boot when awakened. 1038 hibernate(2): No Energy Object features are 1039 available. The Energy Object may be awakened without 1040 requiring a complete boot, but the time for availability is 1041 longer than sleep(3). An example for state hibernate(2) is 1042 a save to-disk state where DRAM context is not maintained. 1043 Typically, energy consumption is zero or close to zero. 1045 sleep(3) : No Energy Object features are 1046 available, except for out-of-band management, such as wake- 1047 up mechanisms. The time for availability is longer than 1048 standby(4). An example for state sleep(3) is a save-to-RAM 1049 state, where DRAM context is maintained. Typically, energy 1050 consumption is close to zero. 1052 standby(4) : No Energy Object features are 1053 available, except for out-of-band management, such as wake- 1054 up mechanisms. This mode is analogous to cold-standby. 1055 The time for availability is longer than ready(5). For 1056 example processor context is may not be maintained. 1057 Typically, energy consumption is close to zero. 1059 ready(5) : No Energy Object features are 1060 available, except for out-of-band management, such as wake- 1061 up mechanisms. This mode is analogous to hot-standby. The 1062 Energy Object can be quickly transitioned into an 1063 operational state. For example, processors are not 1064 executing, but processor context is maintained. 1066 lowMinus(6) : Indicates some Energy Object 1067 features may not be available and the Energy Object has 1068 taken measures or selected options to use less energy than 1069 low(7). 1071 low(7) : Indicates some features may not be 1072 available and the Energy Object has taken measures or 1073 selected options to use less energy than mediumMinus(8). 1075 mediumMinus(8): Indicates all Energy Object 1076 features are available but the Energy Object has taken 1077 measures or selected options to use less energy than 1078 medium(9). 1080 medium(9) : Indicates all Energy Object features 1081 are available but the Energy Object has taken measures or 1082 selected options to use less energy than highMinus(10). 1084 highMinus(10): Indicates all Energy Object 1085 features are available and has taken measures or selected 1086 options to use less energy than high(11). 1088 high(11) : Indicates all Energy Object features 1089 are available and the Energy Object may use the maximum 1090 energy as indicated by the Nameplate Power. 1092 6.5.5. Power State Sets Comparison 1094 A comparison of Power States from different Power State 1095 Sets can be seen in the following table: 1096 IEEE1621 DMTF ACPI EMAN 1098 Non-operational states 1099 off Off-Hard G3, S5 mechoff(0) 1100 off Off-Soft G2, S5 softoff(1) 1101 off Hibernate G1, S4 hibernate(2) 1102 sleep Sleep-Deep G1, S3 sleep(3) 1103 sleep Sleep-Light G1, S2 standby(4) 1104 sleep Sleep-Light G1, S1 ready(5) 1106 Operational states: 1107 on on G0, S0, P5 lowMinus(6) 1108 on on G0, S0, P4 low(7) 1109 on on G0, S0, P3 mediumMinus(8) 1110 on on G0, S0, P2 medium(9) 1111 on on G0, S0, P1 highMinus(10) 1112 on on G0, S0, P0 high(11) 1114 6.6. Relationships 1116 The Energy Object (Class) contains a set of Relationship 1117 (Class) attributes to model the relationships between 1118 devices and components. Two Energy Objects can establish 1119 an Energy Object Relationship to model the deployment 1120 topology with respect to Energy Management. 1122 Relationships are modeled with a Relationship (Class) that 1123 contains the UUID of the other participant in the 1124 relationship and a name that describes the type of 1125 relationship [CHEN]. The types of relationships are: Power 1126 Source, Metering, and Aggregations. 1128 o A Power Source Relationship is relationship where one 1129 Energy Object provides power to one or more Energy 1130 Objects. The Power Source Relationship gives a view 1131 of the physical wiring topology. For example: a data 1132 center server receiving power from two specific Power 1133 Interfaces from two different PDUs. 1135 Note: A Power Source Relationship may or may not 1136 change as the direction of power changes between two 1137 Energy Objects. The relationship may remain to 1138 indicate the change of power direction was unintended 1139 or an error condition. 1141 o A Metering Relationship is relationship where one 1142 Energy Object measures power, energy, demand or Power 1143 Attributes of one or more other Energy Objects. The 1144 Metering Relationship gives the view of the metering 1145 topology. Physical meters can be placed anywhere in 1146 a power distribution tree. For example, utility 1147 meters monitor and report accumulated power 1148 consumption of the entire building. Logically, the 1149 metering topology overlaps with the wiring topology, 1150 as meters are connected to the wiring topology. A 1151 typical example is meters that clamp onto the 1152 existing wiring. 1154 o An Aggregation Relationship is a relationship where 1155 one Energy Object aggregates Energy Management 1156 information of one or more other Energy Objects. The 1157 Aggregation Relationship gives a model of devices 1158 that may aggregate (sum, average, etc) values for 1159 other devices. The Aggregation Relationship is 1160 slightly different compared to the other 1161 relationships as this refers more to a management 1162 function. 1164 In some situations, it is not possible to discover the 1165 Energy Object relationships, and an EnMS or administrator 1166 must set them. Given that relationships can be assigned 1167 manually, the following sections describe guidelines for 1168 use. 1170 6.6.1. Relationship Conventions and Guidelines 1172 This Energy Management framework does not impose many 1173 "MUST" rules related to Energy Object Relationships. There 1174 are always corner cases that could be excluded with too 1175 strict specifications of relationships. However, the 1176 framework proposes a series of guidelines, indicated with 1177 "SHOULD" and "MAY". 1179 6.6.2. Guidelines: Power Source 1181 Power Source relationships are intended to identify the 1182 connections between Power Interfaces. This is analogous to 1183 a Layer 2 connection in networking devices (a "one-hop 1184 connection"). 1186 The preferred modeling would be for Power Interfaces to 1187 participate in Power Source Relationships. It some cases 1188 Energy Objects may not have the capability to model Power 1189 Interfaces. Therefore a Power Source Relationship can be 1190 established between two Energy Objects or two non-connected 1191 Power Interfaces. 1193 While strictly speaking Components and Power Interfaces on 1194 the same Device do provide or receive energy from each 1195 other, the Power Source relationship is intended to show 1196 energy transfer between Devices. Therefore the relationship 1197 is implied when on the same Device. 1199 An Energy Object SHOULD NOT establish a Power Source 1200 Relationship with a Component. 1201 o A Power Source Relationship SHOULD be established 1202 with the next known Power Interface in the wiring 1203 topology. 1205 o The next known Power Interface in the wiring topology 1206 would be the next device implementing the framework. 1207 In some cases the domain of devices under management 1208 may include some devices that do not implement the 1209 framework. In these cases, the Power Source 1210 relationship can be established with the next device 1211 in the topology that implements the framework and 1212 logically shows the Power Source of the device. 1214 o Transitive Power Source relationships SHOULD NOT be 1215 established. For example, if an Energy Object A has 1216 a Power Source Relationship "Poweredby" with the 1217 Energy Object B, and if the Energy Object B has a 1218 Power Source Relationship "Poweredby" with the Energy 1219 Object C, then the Energy Object A SHOULD NOT have a 1220 Power Source Relationship "Poweredby" with the Energy 1221 Object C. 1223 6.6.3. Guidelines: Metering Relationship 1225 Metering Relationships are intended to show when one device 1226 acting as a meter is measuring the power or energy at a 1227 point in a power distribution system. Since one point of a 1228 power distribution system may cover many devices within a 1229 wiring topology, this relationship type can be seen as a 1230 set. 1232 Some devices, however, may include measuring hardware for 1233 components, and outlets or for the entire device. For 1234 example, some PDUs may have the ability to measure power 1235 for each outlet and are commonly referred to as metered-by- 1236 outlet. Others may be able to control power at each power 1237 outlet but can only measure power at the power inlet - 1238 commonly referred to as metered-by-device. 1240 While the Metering Relationship could be used to represent 1241 a device as metered-by-outlet or metered-by-device, the 1242 Metering Relationship SHOULD be used to model the 1243 relationship between a meter and all devices covered by the 1244 meter downstream in the power distribution system 1246 In general: 1247 o A Metering Relationship MAY be established with any 1248 other Energy Object, Component, or Power Interface. 1250 o Transitive Metering Relationships MAY be used. 1252 o When there is a series of meters for one Energy 1253 Object, the Energy Object MAY establish a Metering 1254 relationship with one or more of the meters. 1256 6.6.4. Guidelines: Aggregation 1258 Aggregation relationships are intended to identify when one 1259 device is used to accumulate values from other devices. 1260 Typically this is for energy or power values among devices 1261 and not for Components or Power Interfaces on the same 1262 device. 1264 The intent of Aggregation relationships is to indicate when 1265 one device is providing aggregate values for a set of other 1266 devices when it is not obvious from the power source or 1267 simple containment within a device. 1269 Establishing aggregation relationships within the same 1270 device would make modeling more complex and the aggregated 1271 values can be implied from the use of Power Inlets, outlet 1272 and Energy Object values on the same device. 1274 Since an EnMS is naturally a point of aggregation it is not 1275 necessary to model aggregation for Energy Management 1276 Systems. 1278 The Aggregation Relationship is intended for power and 1279 energy. It MAY be used for aggregation of other values from 1280 the information model, but the rules and logical ability to 1281 aggregate each attribute is out of scope for this document. 1283 In general: 1285 o A Device SHOULD NOT establish an Aggregation 1286 Relationship with Components contained on the same 1287 device. 1288 o A Device SHOULD NOT establish an Aggregation 1289 Relationship with the Power Interfaces contained on 1290 the same device. 1291 o A Device SHOULD NOT establish an Aggregation 1292 Relationship with an EnMS. 1293 o Aggregators SHOULD log or provide notification in the 1294 case of errors or missing values while performing 1295 aggregation. 1297 6.6.5. Energy Object Relationship Extensions 1299 This framework for Energy Management is based on three 1300 relationship types: Aggregation , Metering, and Power 1301 Source. 1302 This framework is defined with possible future extension of 1303 new Energy Object Relationships in mind. 1304 For example: 1305 o Some Devices that may not be IP connected. This can 1306 be modeled with a proxy relationship to an Energy 1307 Object within the domain. This type of proxy 1308 relationship is left for further development. 1309 o A Power Distribution Unit (PDU) that allows devices 1310 and components like outlets to be "ganged" together 1311 as a logical entity for simplified management 1312 purposes, could be modeled with an extension called a 1313 "gang relationship", whose semantics would specify 1314 the Energy Objects' grouping. 1316 7. Energy Management Information Model 1318 This section presents an information model expression of 1319 the concepts in this framework as a reference for 1320 implementers. The information model is implemented as MIB 1321 modules in the different related IETF EMAN documents. 1322 However, other programming structures with different data 1323 models could be used as well. 1325 Data modeling specifications of this information model may 1326 where needed specify which attributes are required or 1327 optional. 1329 Syntax 1331 UML Construct 1332 [ISO-IEC-19501-2005] Equivalent Notation 1333 -------------------- ------------------------------------ 1334 Notes // Notes 1335 Class 1336 (Generalization) CLASS name {member..} 1337 Sub-Class 1338 (Specialization) CLASS subclass 1339 EXTENDS superclass {member..} 1340 Class Member 1341 (Attribute) attribute : type 1343 Model 1345 CLASS EnergyObject { 1347 // identification / classification 1348 index : int 1349 identifier : uuid 1350 alternatekey : string 1352 // context 1353 domainName : string 1354 role : string 1355 keywords [0..n] : string 1356 importance : int 1358 // relationship 1359 relationships [0..n] : Relationship 1361 // measurements 1362 nameplate : Nameplate 1363 power : PowerMeasurement 1364 energy : EnergyMeasurment 1365 demand : DemandMeasurement 1367 // control 1368 powerControl [0..n] : PowerStateSet 1369 } 1370 CLASS PowerInterface EXTENDS EnergyObject{ 1371 eoIfType : enum { inlet, outlet, both} 1372 } 1374 CLASS Device EXTENDS EnergyObject { 1375 eocategory : enum { producer, consumer, meter, 1376 distributor, store } 1377 powerInterfaces[0..n]: PowerInterface 1378 components [0..n] : Component 1379 } 1381 CLASS Component EXTENDS EnergyObject 1382 eocategory : enum { producer, consumer, meter, 1383 distributor, store } 1384 powerInterfaces[0..n]: PowerInterface 1385 components [0..n] : Component 1387 } 1389 CLASS Nameplate { 1390 nominalPower : PowerMeasurement 1391 details : URI 1392 } 1394 CLASS Relationship { 1395 relationshipType : enum { meters, meteredby, 1396 powers, poweredby, aggregates, aggregatedby } 1397 relationshipObject : uuid 1398 } 1400 CLASS Measurement { 1401 multiplier: enum { -24..24} 1402 caliber : enum { actual, estimated, static } 1403 accuracy : enum { 0..10000} // hundreds of percent 1404 } 1406 CLASS PowerMeasurement EXTENDS Measurement { 1407 value : long 1408 units : "W" 1409 powerAttribute : PowerAttribute 1410 } 1412 CLASS EnergyMeasurement EXTENDS Measurement { 1413 startTime : time 1414 units : "kWh" 1415 provided : long 1416 used : long 1417 produced : long 1418 stored : long 1420 } 1422 CLASS TimedMeasurement EXTENDS Measurement { 1423 startTime : timestamp 1424 value : Measurement 1425 maximum : Measurement 1426 } 1428 CLASS TimeInterval { 1429 value : long 1430 units : enum { seconds, miliseconds,...} 1431 } 1433 CLASS DemandMeasurement EXTENDS Measurement { 1434 intervalLength : TimeInterval 1435 intervals : long 1436 intervalMode : enum { periodic, sliding, total } 1437 intervalWindow : TimeInterval 1438 sampleRate : TimeInterval 1439 status : enum { active, inactive } 1440 measurements[0..n] : TimedMeasurements 1441 } 1443 CLASS PowerStateSet { 1444 powerSetIdentifier : int 1445 name : string 1446 powerStates [0..n] : PowerState 1447 operState : int 1448 adminState : int 1449 reason : string 1450 configuredTime : timestamp 1451 } 1453 CLASS PowerState { 1454 powerStateIdentifier : int 1455 name : string 1456 cardinality : int 1457 maximumPower : PowerMeasurement 1458 totalTimeInState : time 1459 entryCount : long 1460 } 1462 CLASS PowerAttribute { 1463 acQuality : ACQuality 1464 } 1466 CLASS ACQuality { 1467 acConfiguration : enum {SNGL, DEL,WYE} 1468 avgVoltage : long 1469 avgCurrent : long 1470 frequency : long 1471 unitMultiplier : int 1472 accuracy : int 1473 totalActivePower : long 1474 totalReactivePower : long 1475 totalApparentPower : long 1476 totalPowerFactor : long 1477 phases [0..2] : ACPhase 1478 } 1480 CLASS ACPhase { 1481 phaseIndex : long 1482 avgCurrent : long 1483 activePower : long 1484 reactivePower : long 1485 apparentPower : long 1486 powerFactor : long 1487 } 1489 CLASS DelPhase EXTENDS ACPhase { 1490 phaseToNextPhaseVoltage : long 1491 thdVoltage : long 1492 thdCurrent : long 1493 } 1495 CLASS WYEPhase EXTENDS ACPhase { 1496 phaseToNeutralVoltage : long 1497 thdCurrent : long 1498 thdVoltage : long 1499 } 1501 8. Modeling Relationships between Devices 1503 In this section we give examples of how to use the EMAN 1504 information model to model physical topologies. Where 1505 applicable, we show how the framework can be applied when 1506 devices can be modeled with Power Interfaces. We also show 1507 how the framework can be applied when devices cannot be 1508 modeled with Power Interfaces but only monitored or control 1509 as a whole. For instance, a PDU may only be able to measure 1510 power and energy for the entire unit without the ability to 1511 distinguish among the inlets or outlets. 1513 8.1. Power Source Relationship 1515 The Power Source relationship is used to model the 1516 interconnections between devices, components and/Power 1517 Interfaces to indicate the source of energy for a device. 1519 In the following examples we show variations on modeling 1520 the reference topologies using relationships. 1522 Given for all cases: 1524 Device W: A computer with one power supply. Power Interface 1525 1 is an inlet for Device W. 1527 Device X: A computer with two power supplies. Power 1528 Interface 1 and power interface 2 are both inlets for 1529 Device X. 1531 Device Y: A PDU with multiple Power Interfaces numbered 1532 0..10. Power Interface 0 is an inlet and Power Interface 1533 1..10 are outlets. 1535 Device Z: A PDU with multiple Power Interfaces numbered 1536 0..10. Power Interface 0 is an inlet and Power Interface 1537 1..10 are outlets. 1539 Case 1: Simple Device with one Source 1541 Physical Topology: 1543 o Device W inlet 1 is plugged into Device Y outlet 8. 1545 With Power Interfaces: 1547 o Device W has an Energy Object representing the 1548 computer itself as well as one Power Interface 1549 defined as an inlet. 1550 o Device Y would have an Energy Object representing the 1551 PDU itself (the Device), with a Power Interface 0 1552 defined as an inlet and Power Interfaces 1..10 1553 defined as outlets. 1555 The interfaces of the devices would have a Power Source 1556 Relationship such that: 1557 Device W inlet 1 is powered by Device Y outlet 8. 1559 +-------+------+ poweredBy +------+----------+ 1560 | PDU Y | PI 8 |-----------------| PI 1 | Device W | 1561 +-------+------+ powers +------+----------+ 1563 Without Power Interfaces: 1565 o Device W has an Energy Object representing the 1566 computer. 1568 o Device Y would have an Energy Object representing the 1569 PDU. 1571 The devices would have a Power Source Relationship such 1572 that: 1573 Device W is powered by Device Y. 1575 +----------+ poweredBy +------------+ 1576 | PDU Y |-----------------| Device W | 1577 +----------+ powers +------------+ 1579 Case 2: Multiple Inlets 1581 Physical Topology: 1582 o Device X inlet 1 is plugged into Device Y outlet 8. 1583 o Device X inlet 2 is plugged into Device Y outlet 9. 1585 With Power Interfaces: 1587 o Device X has an Energy Object representing the 1588 computer itself. It contains two Power Interfaces 1589 defined as inlets. 1590 o Device Y would have an Energy Object representing the 1591 PDU itself (the Device), with a Power Interface 0 1592 defined as an inlet and Power Interfaces 1..10 1593 defined as outlets. 1595 The interfaces of the devices would have a Power Source 1596 Relationship such that: 1597 Device X inlet 1 is powered by Device Y outlet 8. 1598 Device X inlet 2 is powered by Device Y outlet 9. 1600 +-------+------+ poweredBy+------+----------+ 1601 | | PI 8 |-----------------| PI 1 | | 1602 | | |powers | | | 1603 | PDU Y +------+ poweredBy+------+ Device X | 1604 | | PI 9 |-----------------| PI 2 | | 1605 | | |powers | | | 1606 +-------+------+ +------+----------+ 1608 Without Power Interfaces: 1610 o Device X has an Energy Object representing the 1611 computer. Device Y has an Energy Object representing 1612 the PDU. 1614 The devices would have a Power Source Relationship such 1615 that: 1616 Device X is powered by Device Y. 1618 +----------+ poweredBy +------------+ 1619 | PDU Y |-----------------| Device X | 1620 +----------+ powers +------------+ 1622 Case 3: Multiple Sources 1624 Physical Topology: 1625 o Device X inlet 1 is plugged into Device Y outlet 8. 1626 o Device X inlet 2 is plugged into Device Z outlet 9. 1628 With Power Interfaces: 1630 o Device X has an Energy Object representing the 1631 computer itself. It contains two Power Interface 1632 defined as inlets. 1633 o Device Y would have an Energy Object representing the 1634 PDU itself (the Device), with a Power Interface 0 1635 defined as an inlet and Power Interfaces 1..10 1636 defined as outlets. 1637 o Device Z would have an Energy Object representing the 1638 PDU itself (the Device), with a Power Interface 0 1639 defined as an inlet and Power Interfaces 1..10 1640 defined as outlets. 1642 The interfaces of the devices would have a Power Source 1643 Relationship such that: 1644 Device X inlet 1 is powered by Device Y outlet 8. 1645 Device X inlet 2 is powered by Device Z outlet 9. 1647 +-------+------+ poweredBy+------+----------+ 1648 | PDU Y | PI 8 |-----------------| PI 1 | | 1649 | | |powers | | | 1650 +-------+------+ +------+ | 1651 | Device X | 1652 +-------+------+ poweredBy+------+ | 1653 | PDU Z | PI 9 |-----------------| PI 2 | | 1654 | | |powers | | | 1655 +-------+------+ +------+----------+ 1657 Without Power Interfaces: 1659 o Device X has an Energy Object representing the 1660 computer. Device Y and Z would both have respective 1661 Energy Objects representing each entire PDU. 1663 The devices would have a Power Source Relationship such 1664 that: 1665 Device X is powered by Device Y and powered by Device Z. 1667 +----------+ poweredBy +------------+ 1668 | PDU Y |---------------------| Device X | 1669 +----------+ powers +------------+ 1671 +----------+ poweredBy +------------+ 1672 | PDU Z |---------------------| Device X | 1673 +----------+ powers +------------+ 1675 8.2. Metering Relationship 1677 A meter in a power distribution system can logically 1678 measure the power or energy for all devices downstream from 1679 the meter in the power distribution system. As such, a 1680 Metering relationship can be seen as a relationship between 1681 a meter and all of the devices downstream from the meter. 1683 We define in this case a Metering relationship between a 1684 meter and devices downstream from the meter. 1686 +-----+---+ meteredBy +--------+ poweredBy +-------+ 1687 |Meter| PI|--------------| switch |-------------| phone | 1688 +-----+---+ meters +--------+ powers +-------+ 1689 | | 1690 | meteredBy | 1691 +-------------------------------------------+ 1692 meters 1694 In cases where the Power Source topology cannot be 1695 discovered or derived from the information available in the 1696 Energy Management Domain, the metering topology can be used 1697 to relate the upstream meter to the downstream devices in 1698 the absence of specific Power Source relationships. 1700 A Metering Relationship can occur between devices that are 1701 not directly connected, as shown in the following figure: 1703 +---------------+ 1704 | Device 1 | 1705 +---------------+ 1706 | PI | 1707 +---------------+ 1708 | 1709 +---------------+ 1710 | Meter | 1711 +---------------+ 1712 . 1713 . 1714 . 1715 meters meters meters 1716 +----------+ +----------+ +-----------+ 1717 | Device A | | Device B | | Device C | 1718 +----------+ +----------+ +-----------+ 1720 An analogy to communications networks would be modeling 1721 connections between servers (meters) and clients (devices) 1722 when the complete Layer 2 topology between the servers and 1723 clients is not known. 1725 8.3. Aggregation Relationship 1727 Some devices can act as aggregation points for other 1728 devices. For example, a PDU controller device may contain 1729 the summation of power and energy readings for many PDU 1730 devices. The PDU controller will have aggregate values for 1731 power and energy for a group of PDU devices. 1733 This aggregation is independent of the physical power or 1734 communication topology. 1736 The functions that the aggregation point may perform 1737 include the calculation of values such as average, count, 1738 maximum, median, minimum, or the listing (collection) of 1739 the aggregation values, etc. 1740 Based on the experience gained on aggregations at the IETF 1741 [RFC7015], the aggregation function in the EMAN framework 1742 is limited to the summation. 1744 When aggregation occurs across a set of entities, values to 1745 be aggregated may be missing for some entities. The EMAN 1746 framework does not specify how these should be treated, as 1747 different implementations may have good reason to take 1748 different approaches. One common treatment is to define 1749 the aggregation as missing if any of the constituent 1750 elements are missing (useful to be most precise). Another 1751 is to treat the missing value as zero (useful to have 1752 continuous data streams). 1754 The specifications of aggregation functions are out of 1755 scope of the EMAN framework, but must be clearly specified 1756 by the equipment vendor. 1758 9. Relationship to Other Standards 1760 This Energy Management framework uses, as much as possible, 1761 existing standards especially with respect to information 1762 modeling and data modeling [RFC3444]. 1764 The data model for power- and energy-related objects is 1765 based on [IEC61850]. 1767 Specific examples include: 1768 o The scaling factor, which represents Energy Object 1769 usage magnitude, conforms to the [IEC61850] 1770 definition of unit multiplier for the SI (System 1771 International) units of measure. 1772 o The electrical characteristic is based on the ANSI 1773 and IEC Standards, which require that we use an 1774 accuracy class for power measurement. ANSI and IEC 1775 define the following accuracy classes for power 1776 measurement: 1777 o IEC 62053-22 60044-1 class 0.1, 0.2, 0.5, 1 3. 1778 o ANSI C12.20 class 0.2, 0.5 1779 o The electrical characteristics and quality adhere 1780 closely to the [IEC61850-7-4] standard for describing 1781 AC measurements. 1782 o The power state definitions are based on the DMTF 1783 Power State Profile and ACPI models, with operational 1784 state extensions. 1786 10. Implementation Status 1788 RFC Editor Note: Please remove this section and the 1789 reference to [RFC6982] before publication. 1791 This section records the status of known implementations of 1792 the protocol defined by this specification at the time of 1793 posting of this Internet-Draft, and is based on a proposal 1794 described in [RFC6982]. The description of implementations 1795 in this section is intended to assist the IETF in its 1796 decision processes in progressing drafts to RFCs. Please 1797 note that the listing of any individual implementation here 1798 does not imply endorsement by the IETF. Furthermore, no 1799 effort has been spent to verify the information presented 1800 here that was supplied by IETF contributors. This is not 1801 intended as, and must not be construed to be, a catalog of 1802 available implementations or their features. Readers are 1803 advised to note that other implementations may exist. 1805 According to RFC 6982, "this will allow reviewers and 1806 working groups to assign due consideration to documents 1807 that have the benefit of running code, which may serve as 1808 evidence of valuable experimentation and feedback that have 1809 made the implemented protocols more mature. 1811 Implementation descriptions for this document are 1812 maintained at: 1813 http://tools.ietf.org/wg/eman/trac/wiki/EmanImplementations 1815 11. Security Considerations 1817 Regarding the data attributes specified here, some or all 1818 may be considered sensitive or vulnerable in some network 1819 environments. Reading or writing these attributes without 1820 proper protection such as encryption or access 1821 authorization will have negative effects on network 1822 capabilities. Event logs for audit purposes on 1823 configuration and other changes should be generated 1824 according to current authorization, audit, and accounting 1825 principles to facilitate investigations (compromise or 1826 benign mis-configurations) or any reporting requirements. 1828 The information and control capabilities specified in this 1829 framework could be exploited with detriment to a site or 1830 deployment. Implementers of the framework SHOULD examine 1831 and mitigate security threats with respect to these new 1832 capabilities. 1834 [RFC3410] User Security Model for SNMPv3 presents a good 1835 description of threats and mitigations for the SNMPv3 1836 protocol that can be used as a guide for implementations of 1837 this framework using other protocols. 1839 11.1. Security Considerations for SNMP 1841 Readable objects in MIB modules (i.e., objects with a MAX- 1842 ACCESS other than not-accessible) may be considered 1843 sensitive or vulnerable in some network environments. It 1844 is important to control GET and/or NOTIFY access to these 1845 objects and possibly to encrypt the values of these objects 1846 when sending them over the network via SNMP. 1848 The support for SET operations in a non-secure environment 1849 without proper protection can have a negative effect on 1850 network operations. 1852 For example: 1853 o Unauthorized changes to the Energy Management Domain 1854 or business context of a device will result in 1855 misreporting or interruption of power. 1856 o Unauthorized changes to a power state will disrupt 1857 the power settings of the different devices, and 1858 therefore the state of functionality of the 1859 respective devices. 1860 o Unauthorized changes to the demand history will 1861 disrupt proper accounting of energy usage. 1863 With respect to data transport, SNMP versions prior to 1864 SNMPv3 did not include adequate security. Even if the 1865 network itself is secure (for example, by using IPsec), 1866 there is still no secure control over who on the secure 1867 network is allowed to access and GET/SET 1868 (read/change/create/delete) the objects in these MIB 1869 modules. 1871 It is recommended that implementers consider the security 1872 features as provided by the SNMPv3 framework (see 1873 [RFC3410], section 8), including full support for the 1874 SNMPv3 cryptographic mechanisms (for authentication and 1875 confidentiality). 1877 Further, deployment of SNMP versions prior to SNMPv3 is not 1878 recommended. Instead, it is recommended to deploy SNMPv3 1879 and to enable cryptographic security. It is then a 1880 customer/operator responsibility to ensure that the SNMP 1881 entity giving access to an instance of these MIB modules is 1882 properly configured to give access to the objects only to 1883 those principals (users) that have legitimate rights to GET 1884 or SET (change/create/delete) them. 1886 12. IANA Considerations 1887 12.1. IANA Registration of new Power State Sets 1889 This document specifies an initial set of Power State Sets. 1890 The list of these Power State Sets with their numeric 1891 identifiers is given is Section 6. IANA maintains the lists 1892 of Power State Sets. 1894 New assignments for Power State Set are administered by 1895 IANA through Expert Review [RFC5226], i.e., review by one 1896 of a group of experts designated by an IETF Area Director. 1897 The group of experts must check the requested state for 1898 completeness and accuracy of the description. A pure vendor 1899 specific implementation of Power State Set shall not be 1900 adopted; since it would lead to proliferation of Power 1901 State Sets. 1903 Power states in a Power State Set are limited to 255 1904 distinct values. New Power State Set must be assigned the 1905 next available numeric identifier that is a multiple of 1906 256. 1908 12.1.1. IANA Registration of the IEEE1621 Power State Set 1910 This document specifies a set of values for the IEEE1621 1911 Power State Set [IEEE1621]. The list of these values with 1912 their identifiers is given in Section 6.5.2. IANA created 1913 a new registry for IEEE1621 Power State Set identifiers and 1914 filled it with the initial list of identifiers. 1916 New assignments (or potentially deprecation) for the 1917 IEEE1621 Power State Set is administered by IANA through 1918 Expert Review [RFC5226], i.e., review by one of a group of 1919 experts designated by an IETF Area Director. The group of 1920 experts must check the requested state for completeness and 1921 accuracy of the description. 1923 12.1.2. IANA Registration of the DMTF Power State Set 1925 This document specifies a set of values for the DMTF Power 1926 State Set. The list of these values with their identifiers 1927 is given in Section 6.5.3. IANA has created a new registry 1928 for DMTF Power State Set identifiers and filled it with the 1929 initial list of identifiers. 1931 New assignments (or potentially deprecation) for the DMTF 1932 Power State Set is administered by IANA through Expert 1933 Review [RFC5226], i.e., review by one of a group of experts 1934 designated by an IETF Area Director. The group of experts 1935 must check the conformance with the DMTF standard [DMTF], 1936 on the top of checking for completeness and accuracy of the 1937 description. 1939 12.1.3. IANA Registration of the EMAN Power State Set 1941 This document specifies a set of values for the EMAN Power 1942 State Set. The list of these values with their identifiers 1943 is given in Section 6.5.4. IANA has created a new registry 1944 for EMAN Power State Set identifiers and filled it with the 1945 initial list of identifiers. 1947 New assignments (or potentially deprecation) for the EMAN 1948 Power State Set is administered by IANA through Expert 1949 Review [RFC5226], i.e., review by one of a group of experts 1950 designated by an IETF Area Director. The group of experts 1951 must check the requested state for completeness and 1952 accuracy of the description. 1954 12.1.4. Batteries Power State Set 1956 Batteries have operational and administrational states that 1957 could be represented as a Power State Set. Since the work 1958 for battery management is parallel to this document, we are 1959 not proposing any Power State Sets for batteries at this 1960 time. 1962 12.2. Updating the Registration of Existing Power State Sets 1964 With the evolution of standards, over time, it may be 1965 important to deprecate some of the existing the Power State 1966 Sets, or to add or deprecate some Power States within a 1967 Power State Set. 1969 The registrant shall publish an Internet-draft or an 1970 individual submission with the clear specification on 1971 deprecation of Power State Sets or Power States registered 1972 with IANA. The deprecation or addition shall be 1973 administered by IANA through Expert Review [RFC5226], i.e., 1974 review by one of a group of experts designated by an IETF 1975 Area Director. The process should also allow for a 1976 mechanism for cases where others have significant 1977 objections to claims on deprecation of a registration. 1979 13. References 1981 Normative References 1983 [RFC2119] Bradner, S., "Key words for use in RFCs to 1984 Indicate Requirement Levels", BCP 14, RFC 2119, 1985 March 1997 1987 [RFC3410] Case, J., Mundy, R., Partain, D., and B. 1988 Stewart, "Introduction and Applicability 1989 Statements for Internet Standard Management 1990 Framework ", RFC 3410, December 2002 1992 [RFC3444] Pras, A., Schoenwaelder, J. "On the Differences 1993 between Information Models and Data Models", RFC 1994 3444, January 2003 1996 [RFC4122] Leach, P., Mealling, M., and R. Salz," A 1997 Universally Unique Identifier (UUID) URN 1998 Namespace", RFC 4122, July 2005 2000 [RFC5226] Narten, T., and H. Alvestrand, "Guidelines for 2001 Writing an IANA Considerations Section in RFCs", 2002 RFC 5226, May 2008 2004 [RFC6933] Bierman, A. and K. McCloghrie, "Entity MIB 2005 (Version4)", RFC 6933, May 2013 2007 [RFC6988] Quittek, J., Chandramouli, M., Winter, R., 2008 Dietz, T., and B. Claise, "Requirements for 2009 Energy Management", RFC 6988, Septembre 2013 2011 [ISO-IEC-19501-2005] ISO/IEC 19501:2005, Information 2012 technology, Open Distributed Processing -- 2013 Unified Modeling Language (UML), January 2005 2015 Informative References 2017 [RFC3986] T. Berners-Lee, Ed., " Uniform Resource 2018 Identifier (URI): Generic Syntax", RFC3 986, 2019 January 2005 2021 [RFC6982] Y. Sheffer, and Adrian Farrel, "Improving 2022 Awareness of Running Code: The Implementation 2023 Status Section", RFC 6982, July 2013 2025 [RFC7015] B. Trammell, A. Wagner, and B. Claise, "Flow 2026 Aggregation for the IP Flow Information Export 2027 (IPFIX) Protocol", RFC 7015, September 2013 2029 [ACPI] "Advanced Configuration and Power Interface 2030 Specification", http://www.acpi.info/spec30b.htm 2032 [IEEE1621] "Standard for User Interface Elements in Power 2033 Control of Electronic Devices Employed in 2034 Office/Consumer Environments", IEEE 1621, 2035 December 2004 2037 [ITU-T-M-3400] TMN Recommendation on Management Functions 2038 (M.3400), 1997 2040 [NMF] "Network Management Fundamentals", Alexander Clemm, 2041 ISBN: 1-58720-137-2, 2007 2043 [TMN] "TMN Management Functions : Performance Management", 2044 ITU-T M.3400 2046 [IEEE100] "The Authoritative Dictionary of IEEE Standards 2047 Terms" 2048 http://ieeexplore.ieee.org/xpl/mostRecentIssue.js 2049 p?punumber=4116785 2051 [ISO50001] "ISO 50001:2011 Energy management systems - 2052 Requirements with guidance for use", 2053 http://www.iso.org/ 2055 [IEC60050] International Electrotechnical Vocabulary 2056 http://www.electropedia.org/iev/iev.nsf/welcome?o 2057 penform 2059 [IEC61850] Power Utility Automation, 2060 http://www.iec.ch/smartgrid/standards/ 2062 [IEC61850-7-2] Abstract communication service interface 2063 (ACSI), http://www.iec.ch/smartgrid/standards/ 2065 [IEC61850-7-4] Compatible logical node classes and data 2066 classes, http://www.iec.ch/smartgrid/standards/ 2068 [DMTF] "Power State Management Profile DMTF DSP1027 2069 Version 2.0" December 2009 2070 http://www.dmtf.org/sites/default/files/standards 2071 /documents/DSP1027_2.0.0.pdf 2073 [IPENERGY] R. Aldrich, J. Parello "IP-Enabled Energy 2074 Management", 2010, Wiley Publishing 2076 [X.700] CCITT Recommendation X.700 (1992), Management 2077 framework for Open Systems Interconnection (OSI) 2078 for CCITT applications 2080 [ASHRAE-201] "ASHRAE Standard Project Committee 201 2081 (SPC 201)Facility Smart Grid Information 2082 Model", http://spc201.ashraepcs.org 2084 [CHEN] "The Entity-Relationship Model: Toward a Unified 2085 View of Data", Peter Pin-shan Chen, ACM 2086 Transactions on Database Systems, 1976 2088 [CISCO-EW] "Cisco EnergyWise Design Guide", John Parello, 2089 Roland Saville, Steve Kramling, Cisco Validated 2090 Designs, September 2010, 2091 http://www.cisco.com/en/US/docs/solutions/Enterpr 2092 ise/Borderless_Networks/Energy_Management/energyw 2093 isedg.html 2095 14. Acknowledgments 2097 The authors would like to thank Michael Brown for his 2098 editorial work improving the text dramatically. Thanks to 2099 Rolf Winter for his feedback and to Bill Mielke for 2100 feedback and very detailed review. Thanks to Bruce Nordman 2101 for brainstorming with numerous conference calls and 2102 discussions. Finally, the authors would like to thank the 2103 EMAN chairs: Nevil Brownlee, Bruce Nordman, and Tom Nadeau. 2105 This document was prepared using 2-Word-v2.0.template.dot. 2107 Appendix A. 2108 Information Model Listing 2110 EnergyObject (Class) 2112 r index Integer An RFC6933 2113 entPhysicalIndex 2115 w name String An RFC6933 2116 entPhysicalName 2118 r identifier uuid An [RFC6933] 2119 entPhysicalUUID 2121 rw alternatekey String A manufacturer defined 2122 string that can be 2123 used to identify the 2124 Energy Object 2126 rw domainName String The name of an Energy 2127 Management domain for 2128 the Energy Object 2130 rw role String An administratively 2131 assigned name to 2132 indicate the purpose 2133 an Energy Object 2134 serves in the network 2136 rw keywords String A list of keywords or 2137 [0..n] tags that can be used 2138 to group Energy 2139 Objects for reporting 2140 or searching 2142 rw importance Integer Specifies a ranking of 2143 how important the 2144 Energy Object is (on a 2145 scale of 1 to 100) 2146 compared with other 2147 Energy Objects 2149 rw relationships Relationship A list of 2150 [0..n] relationships between 2151 this Energy Object and 2152 other Energy Objects 2154 r nameplate Nameplate The nominal 2155 PowerMeasurement of 2156 the Energy Object as 2157 specified by the 2158 device manufacturer 2160 r power PowerMeasurement The present power 2161 measurement of the 2162 Energy Object 2164 r energy EnergyMeasurment The present energy 2165 measurement for the 2166 Energy Object 2168 r demand DemandMeasurement The present demand 2169 measurement for the 2170 Energy Object 2172 r powerControl PowerStateSet A list of Power States 2173 [0..n] Sets the Energy Object 2174 supports 2176 PowerInterface (Class) inherits from and specializes 2177 EnergyObject 2179 r eoIfType Enumeration Indicates if the Power 2180 Interface is an - 2181 inlet; outlet; both 2183 Device (Class) inherits from and specializes EnergyObject 2185 rw eocategory Enumeration Broadly indicates if 2186 the Device is a 2187 producer consumer meter 2188 distributor or store of 2189 energy 2191 r powerInterfaces PowerInterface A list of 2192 [0..n] PowerInterfaces 2193 contained in this 2194 Device 2196 r components Component A list of Components 2197 [0..n] contained in this 2198 Device 2200 Component (Class) inherits from and specializes 2201 EnergyObject 2203 rw eocategory Enumeration Broadly indicates if 2204 the Component is a 2205 producer consumer meter 2206 distributor or store of 2207 energy 2209 r powerInterfaces PowerInterface A list of 2210 [0..n] PowerInterfaces 2211 contained in this 2212 Component 2214 r components Component A list of Components 2215 [0..n] contained in this 2216 Component 2218 Nameplate (Class) 2220 r nominalPower PowerMeasuremen The nominal power of 2221 t the Energy Object as 2222 specified by the device 2223 manufacturer 2225 rw details URI an [RFC3986] URI that 2226 links to manufacturer 2227 information about the 2228 nominal power of a 2229 device 2231 Relationship (Class) 2233 rw relationshipType Enumeratio A description of the 2234 n relationhip indicating 2235 - meters; meteredby; 2236 powers; poweredby; 2237 aggregates; 2238 aggregatedby 2240 rw relationshipObject uuid An [RFC6933] 2241 entPhysicalUUID that 2242 indicates the other 2243 participating Energy 2244 Object in the 2245 relationship 2247 Measurement (Class) 2249 r multiplier Enumeration The magnitude of the 2250 Measurement in the range - 2251 24..24 2253 r caliber Enumeration Specifies how the Measurement 2254 was obtained - actual; 2255 estimated; static 2257 r accuracy Enumeration Specifies the accuracy of the 2258 measurement if applicable as 2259 0..10000 indicating hundreds 2260 of percent 2262 PowerMeasurement (Class) inherits from and specializes 2263 Measurement 2265 r value Long A measurement value of 2266 power 2268 r units "W" The units of measure for 2269 the power - "Watts" 2271 r powerAttribute PowerAttribute Measurement of the 2272 electrical current; 2273 voltage; phase and/or 2274 frequencies for the 2275 PowerMeasurement 2277 EnergyMeasurement (Class) inherits from and specializes 2278 Measurement 2280 r startTime Time Specifies the start time of the 2281 EnergyMeasurement interval 2283 r units "kWh" The units of measure for the 2284 energy - kilowatt hours 2286 r provided Long A measurement of energy 2287 provided 2289 r used Long A measurement of energy used / 2290 consumed 2292 r produced Long A measurement of energy 2293 produced 2295 r stored Long A measurement of energy stores 2297 TimedMeasurement (Class) inherits from and specializes 2298 Measurement 2300 r startTime timestamp A start time of a measurement 2302 r value Measurement A measurement value 2304 r maximum Measurement A maximum value measured since a 2305 previous timestamp 2307 TimeInterval (Class) 2309 r value Long a value of time 2311 r units Enumeration a magnitude of time express as 2312 seconds with an SI prefix 2313 (miliseconds etc) 2315 DemandMeasurement (Class) inherits from and specializes 2316 Measurement 2318 rw intervalLength TimeInterval The length of time 2319 over which to compute 2320 average energy 2322 rw intervals Long The number of 2323 intervals that can be 2324 measured 2326 rw intervalMode Enumeration The mode of interval 2327 measurement as - 2328 periodic; sliding; 2329 total 2331 rw intervalWindow TimeInterval The duration between 2332 the starting time of 2333 one sliding window and 2334 the next starting time 2336 rw sampleRate TimeInterval The sampling rate at 2337 which to poll power in 2338 order to compute 2339 demand 2341 rw status Enumeration a control to start or 2342 stop demand 2343 measurement as - 2344 active; inactive 2346 r measurements[0.TimedMeasurement a collection of 2347 .n] TimedMeasurements to 2348 compute demand 2350 PowerStateSet (Class) 2352 r powerSetIdentifier Integer an IANA assigned value 2353 indicating a Power 2354 State Set 2356 r name String A Power State Set name 2358 r powerStates [0..n] PowerState a set of Power States 2359 for the given 2360 identifier 2362 rw operState Integer The current 2363 operational Power 2364 State 2366 rw adminState Integer The desired Power 2367 State 2369 rw reason String Describes the reason 2370 for the adminState 2372 r configuredTime timestamp Indicates the time of 2373 the desired Power 2374 State 2376 PowerState (Class) 2378 r powerStateIdentifier Integer an IANA assigned value 2379 indicating a Power State 2381 r name String A name for the Power 2382 State 2384 r cardinality Integer A value indicating an 2385 ordering of the Power 2386 State 2388 rw maximumPower PowerMea indicates the maximum 2389 surement power for the Energy 2390 Object at this Power 2391 State 2393 r totalTimeInState Time Indicates the total time 2394 an Energy Object has 2395 been in this Power State 2396 since last reset 2398 r entryCount Long Indicates the number of 2399 time the Energy Object 2400 has entered changed to 2401 this state 2403 PowerAttribute (Class) 2405 r acQuality ACQuality Describes AC Power Attributes for 2406 a Measurement 2408 ACQuality (Class) 2410 r acConfiguration Enumera Describes the physical 2411 tion configuration of 2412 alternating current as 2413 single phase (SNGL) three 2414 phase delta (DEL) or three 2415 phase Y (WYE) 2417 r avgVoltage Long The average of the voltage 2418 measured over an integral 2419 number of AC cycles 2420 [IEC61850-7-4] 'Vol' 2422 r avgCurrent Long The current per phase 2423 [IEC61850-7-4] 'Amp' 2425 r frequency Long Basic frequency of the AC 2426 circuit [IEC61850-7-4] 'Hz' 2428 r unitMultiplier Integer Magnitude of watts for the 2429 usage value in this 2430 instance 2432 r accuracy Integer Percentage value in 100ths 2433 of a percent representing 2434 the presumed accuracy of 2435 active; reactive; and 2436 apparent power in this 2437 instance 2439 r totalActivePower Long A measured value of the 2440 actual power delivered to 2441 or consumed by the load 2442 [IEC61850-7-4] 'TotW' 2444 r totalReactivePower Long A measured value of the 2445 reactive portion of the 2446 apparent power [IEC61850-7- 2447 4] 'TotVAr' 2449 r totalApparentPower Long A measured value of the 2450 voltage and current which 2451 determines the apparent 2452 power as the vector sum of 2453 real and reactive power 2454 [IEC61850-7-4] 'TotVA' 2456 r totalPowerFactor Long A measured value of the 2457 ratio of the real power 2458 flowing to the load versus 2459 the apparent power 2460 [IEC61850-7-4] 'TotPF' 2462 r phases [0..2] ACPhase A description of the three 2463 phase power 2465 ACPhase (Class) 2467 r phaseIndex Long A phase angle typically 2468 corresponding to - 0; 120; 240 2470 r avgCurrent Long A measured value of the current per 2471 phase [IEC61850-7-4] 'A' 2473 r activePower Long A measured value of the actual 2474 power delivered to or consumed by 2475 the load [IEC61850-7-4] 'W' 2477 r reactivePower Long A measured value of the reactive 2478 portion of the apparent power 2479 [IEC61850-7-4] 'VAr' 2481 r apparentPower Long A measured value of the active plus 2482 reactive power [IEC61850-7-4] 'VA' 2484 r powerFactor Long A measure ratio of the real power 2485 flowing to the load versus the 2486 apparent power for this phase 2488 [IEC61850-7-4] 'PF' 2490 DelPhase (Class) inherits from and specializes ACPhase 2492 r phaseToNextPhas Long A measured value of phase to 2493 eVoltage next phase voltages where the 2494 next phase is [IEC61850-7-4] 2495 'PPV' 2497 r thdVoltage Long A calculated value for the 2498 voltage total harmonic disortion 2499 for phase to next phase. Method 2500 of calculation is not specified 2501 [IEC61850-7-4] 'ThdPPV' 2503 r thdCurrent Long A calculated value for the 2504 voltage total harmonic disortion 2505 (THD) for phase to phase. Method 2506 of calculation is not specified 2507 [IEC61850-7-4] 'ThdPPV' 2509 WYEPhase (Class) inherits from and specializes ACPhase 2511 r phaseToNeutral Long A measured value of phase to 2512 Voltage neutral voltage [IEC61850-7-4] 2513 'PhV' 2515 r thdCurrent Long A measured value of phase currents 2516 [IEC61850-7-4] 'A' 2518 r thdVoltage Long A calculated value of the voltage 2519 total harmonic distortion (THD) 2520 for phase to neutral [IEC61850-7- 2521 4] 'ThdPhV' 2523 Authors' Addresses 2525 John Parello 2526 Cisco Systems, Inc. 2527 3550 Cisco Way 2528 San Jose, California 95134 2529 US 2531 Phone: +1 408 525 2339 2532 Email: jparello@cisco.com 2534 Benoit Claise 2535 Cisco Systems, Inc. 2536 De Kleetlaan 6a b1 2537 Diegem 1813 2538 BE 2540 Phone: +32 2 704 5622 2541 Email: bclaise@cisco.com 2543 Brad Schoening 2544 44 Rivers Edge Drive 2545 Little Silver, NJ 07739 2546 US 2548 Phone: 2549 Email: brad.schoening@verizon.net 2551 Juergen Quittek 2552 NEC Europe Ltd. 2553 Network Laboratories 2554 Kurfuersten-Anlage 36 2555 69115 Heidelberg 2556 Germany 2558 Phone: +49 6221 90511 15 2559 EMail: quittek@netlab.nec.de