idnits 2.17.1 draft-ietf-eman-framework-18.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 458 has weird spacing: '...control mon...' == Line 470 has weird spacing: '...control mon...' == Line 2121 has weird spacing: '...ntifier uui...' == Line 2314 has weird spacing: '...eration a mag...' == Line 2361 has weird spacing: '...erState a se...' == (2 more instances...) -- The document date (April 23, 2014) is 3656 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 23, 2014 B. Schoening 6 Independent Consultant 7 J. Quittek 8 NEC Europe Ltd 10 April 23, 2014 12 Energy Management Framework 13 draft-ietf-eman-framework-18 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 ........................................... 56 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 devices monitored by this framework can be either consumers 119 of energy (such as routers and computer systems) and 120 components of such devices (such as line cards, fans, and 121 disks), or they can be producers of energy (like an 122 uninterruptible power supply or renewable energy system) 123 and their associated components (such as battery cells, 124 inverters, or photovoltaic panels). 126 This framework further describes how to identify, classify 127 and provide context for such devices. While context 128 information is not specific to Energy Management, some 129 context attributes are specified in the framework, 130 addressing the following use cases: how important is a 131 device in terms of its business impact, how should devices 132 be grouped for reporting and searching, and how should a 133 device role be described. Guidelines for using context for 134 Energy Management are described. 136 The framework introduces the concept of a Power Interface 137 that is analogous to a network interface. A Power Interface 138 is defined as an interconnection among devices where energy 139 can be provided, received, or both. 141 The most basic example of Energy Management is a single 142 device reporting information about itself. In many cases, 143 however, energy is not measured by the device itself, but 144 measured upstream in the power distribution tree. For 145 example, a power distribution unit (PDU) may measure the 146 energy it supplies to attached devices and report this to 147 an energy management system. Therefore, devices often have 148 relationships to other devices or components in the power 149 network. An EnMS (Energy Management System) generally 150 requires an understanding of the power topology (who 151 provides power to whom), the metering topology (who meters 152 whom), and an understanding of the potential aggregation 153 (who aggregates values of others). 155 The relationships build on the Power Interface concept. The 156 different relationships among devices and components, 157 specified in this document, include: power source, 158 metering, and aggregation relationships. 160 The framework does not cover non-electrical equipment nor 161 does it cover energy procurement and manufacturing. 163 2. Terminology 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 165 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 166 and "OPTIONAL" in this document are to be interpreted as 167 described in RFC-2119 [RFC2119]. 169 In this document these words will appear with that 170 interpretation only when in ALL CAPS. Lower case uses of 171 these words are not to be interpreted as carrying RFC-2119 172 significance. 174 In this section some terms have a NOTE that is not part of 175 the definition itself, but accounts for differences between 176 terminologies of different standards organizations or 177 further clarifies the definition. 179 The terms are listing in an order that aids in reading 180 where terms may build off a previous term as opposed to an 181 alphabetical ordering. Some terms that are common in 182 electrical engineering or that describe common physical 183 items use a lower case notation. 185 Energy Management 186 Energy Management is a set of functions for measuring, 187 modeling, planning, and optimizing networks to ensure 188 that the network and network attached devices use energy 189 efficiently and appropriately for the nature of the 190 application and the cost constraints of the organization. 192 Reference: Adapted from [ITU-T-M-3400] 194 NOTES: 195 1. Energy Management refers to the activities, methods, 196 procedures and tools that pertain to measuring, modeling, 197 planning, controlling and optimizing the use of energy in 198 networked systems [NMF]. 200 2. Energy Management is a management domain which is 201 congruent to any of the FCAPS areas of management in the 202 ISO/OSI Network Management Model [TMN]. Energy Management 203 for communication networks and attached devices is a 204 subset or part of an organization's greater Energy 205 Management Policies. 207 Energy Management System (EnMS) 208 An Energy Management System is a combination of hardware 209 and software used to administer a network with the 210 primary purpose of energy management. 212 NOTES: 214 1. An Energy Management System according to [ISO50001] 215 (ISO-EnMS) is a set of systems or procedures upon which 216 organizations can develop and implement an energy policy, 217 set targets, action plans and take into account legal 218 requirements related to energy use. An ISO-EnMS allows 219 organizations to improve energy performance and 220 demonstrate conformity to requirements, standards, and/or 221 legal requirements. 223 2. Example ISO-EnMS: Company A defines a set of policies 224 and procedures indicating there should exist multiple 225 computerized systems that will poll energy measurements 226 from their meters and pricing / source data from their 227 local utility. Company A specifies that their CFO (Chief 228 Financial Officer) should collect information and 229 summarize it quarterly to be sent to an accounting firm 230 to produce carbon accounting reporting as required by 231 their local government. 233 3. For the purposes of EMAN, the definition herein is the 234 preferred meaning of an Energy Management System (EnMS). 235 The definition from [ISO50001] can be referred to as ISO 236 Energy Management System (ISO-EnMS). 238 Energy Monitoring 239 Energy Monitoring is a part of Energy Management that 240 deals with collecting or reading information from devices 241 to aid in Energy Management. 243 Energy Control 244 Energy Control is a part of Energy Management that deals 245 with directing influence over devices. 247 electrical equipment 248 A general term including materials, fittings, devices, 249 appliances, fixtures, apparatus, machines, etc., used as 250 a part of, or in connection with, an electric 251 installation. 252 Reference: [IEEE100] 254 non-electrical equipment (mechanical equipment) 255 A general term including materials, fittings, devices, 256 appliances, fixtures, apparatus, machines, etc., used as 257 a part of, or in connection with, non-electrical power 258 installations. 260 Reference: Adapted from [IEEE100] 262 device 263 A piece of electrical or non-electrical equipment. 265 Reference: Adapted from [IEEE100] 267 component 268 A part of an electrical or non-electrical equipment 269 (device). 271 Reference: Adapted from [ITU-T-M-3400] 273 power inlet 274 A power inlet (or simply inlet) is an interface at which 275 a device or component receives energy from another device 276 or component. 278 power outlet 279 A power outlet (or simply outlet) is an interface at 280 which a device or component provides energy to another 281 device or component. 283 energy 284 That which does work or is capable of doing work. As used 285 by electric utilities, it is generally a reference to 286 electrical energy and is measured in kilowatt hours 287 (kWh). 289 Reference: [IEEE100] 291 NOTES 292 1. Energy is the capacity of a system to produce external 293 activity or perform work [ISO50001] 295 power 296 The time rate at which energy is emitted, transferred, or 297 received; usually expressed in watts (joules per second). 299 Reference: [IEEE100] 301 demand 302 The average value of power or a related quantity over a 303 specified interval of time. Note: Demand is expressed in 304 kilowatts, kilovolt-amperes, kilovars, or other suitable 305 units. 307 Reference: [IEEE100] 309 NOTES: 310 1. While IEEE100 defines demand in kilo measurements, for 311 EMAN we use watts with any suitable metric prefix. 313 provide energy 314 A device (or component) "provides" energy to another 315 device if there is an energy flow from this device to the 316 other one. 318 receive energy 319 A device (or component) "receives" energy from another 320 device if there is an energy flow from the other device 321 to this one. 323 meter (energy meter) 324 a device intended to measure electrical energy by 325 integrating power with respect to time. 327 Reference: Adapted from [IEC60050] 329 battery 330 one or more cells (consisting of an assembly of 331 electrodes, electrolyte, container, terminals and usually 332 separators) that are a source and/or store of electric 333 energy. 335 Reference: Adapted from [IEC60050] 337 Power Interface 338 A power inlet, outlet, or both. 340 Nameplate Power 341 The Nameplate Power is the nominal power of a device as 342 specified by the device manufacturer. 344 Power Attributes 345 Measurements of the electrical current, voltage, phase 346 and frequencies at a given point in an electrical power 347 system. 348 Reference: Adapted from [IEC60050] 350 NOTES: 351 1. Power Attributes are not intended to provide any 352 bounds or recommended range for the value. They are 353 simply the reading of the value associated with the 354 attribute in question. 356 Power Quality 357 Characteristics of the electrical current, voltage, phase 358 and frequencies at a given point in an electric power 359 system, evaluated against a set of reference technical 360 parameters. These parameters might, in some cases, relate 361 to the compatibility between electricity supplied in an 362 electric power system and the loads connected to that 363 electric power system. 365 Reference: [IEC60050] 367 NOTES: 368 1. Electrical characteristics representing power quality 369 information are typically required by customer facility 370 energy management systems. It is not intended to satisfy 371 the detailed requirements of power quality monitoring. 372 Standards typically also give ranges of allowed values; 373 the information attributes are the raw measurements, not 374 the "yes/no" determination by the various standards. 376 Reference: [ASHRAE-201] 378 Power State 379 A Power State is a condition or mode of a device (or 380 component) that broadly characterizes its capabilities, 381 power, and responsiveness to input. 383 Reference: Adapted from [IEEE1621] 385 Power State Set 386 A Power State Set is a collection of Power States that 387 comprises a named or logical control grouping. 389 3. Target Devices 391 With Energy Management, there exists a wide variety of 392 devices that may be contained in the same deployment as a 393 communication network but comprise a separate facility, 394 home, or power distribution network. 396 Energy Management has special challenges because a power 397 distribution network supplies energy to devices and 398 components, while a separate communications network 399 monitors and controls the power distribution network. 401 The target devices for Energy Management are all devices 402 that can be monitored or controlled (directly or 403 indirectly) by an Energy Management System (EnMS). These 404 target devices include, for example: 405 . Simple electrical appliances and fixtures 406 . Hosts, such as a PC, a server, or a printer 407 . Switches, routers, base stations, and other network 408 equipment and middle boxes 409 . Components within devices, a line card inside a 410 switch 411 . Batteries as a device or component that is a store 412 of energy 413 . Devices or components that charge or produce energy 414 such as solar cells, charging stations or 415 generators 416 . Power over Ethernet (PoE) endpoints 417 . Power Distribution Units (PDU) 418 . Protocol gateway devices for Building Management 419 Systems (BMS) 420 . Electrical meters 421 . Sensor controllers with subtended sensors 423 Target devices include devices that communicate via the 424 Internet Protocol (IP) as well as devices using other means 425 for communication. The latter are managed through gateways 426 or proxies that can communicate using IP. 428 4. Physical Reference Model 430 The following reference model describes physical power 431 topologies that exist in parallel to a communication 432 topology. While many more topologies can be created with 433 combination of devices, the following are some basic ones 434 that show how Energy Management topologies differ from 435 Network Management topologies. 437 NOTE: "###" is used to denote a transfer of energy. 438 - > is used to denote a transfer of information. 440 Basic Energy Management 442 +--------------------------+ 443 | Energy Management System | 444 +--------------------------+ 445 ^ ^ 446 monitoring | | control 447 v v 448 +---------+ 449 | device | 450 +---------+ 452 Basic Power Supply 454 +-----------------------------------------+ 455 | Energy Management System | 456 +-----------------------------------------+ 457 ^ ^ ^ ^ 458 monitoring | | control monitoring | | control 459 v v v v 460 +--------------+ +-----------------+ 461 | power source |########| device | 462 +--------------+ +-----------------+ 464 Single Power Supply with Multiple Devices 466 +---------------------------------------+ 467 | Energy Management System | 468 +---------------------------------------+ 469 ^ ^ ^ ^ 470 monitoring | | control monitoring | | control 471 v v v v 472 +--------+ +------------------+ 473 | power |########| device 1 | 474 | source | # +------------------+-+ 475 +--------+ #######| device 2 | 476 # +------------------+-+ 477 #######| device 3 | 478 +------------------+ 480 Multiple Power Supplies with Single Devices 482 +----------------------------------------------+ 483 | Energy Management System | 484 +----------------------------------------------+ 485 ^ ^ ^ ^ ^ ^ 486 mon. | | ctrl. mon. | | ctrl. mon. | | ctrl. 487 v v v v v v 488 +----------+ +----------+ +----------+ 489 | power |######| device |######| power | 490 | source 1 | | | | source 2 | 491 +----------+ +----------+ +----------+ 493 5. Not Covered by the Framework 495 While this framework is intended as a framework for Energy 496 Management in general, there are some areas that are not 497 covered. 499 Non-Electrical Equipment 501 The primary focus of this framework is the management of 502 electrical equipment. Non-Electrical equipment, not covered 503 in this framework, could nevertheless be modeled by 504 providing interfaces that comply with the framework: for 505 example, using the same units for power and energy. 506 Therefore, non-electrical equipment that do not convert-to 507 or present-as equivalent to electrical equipment are not 508 addressed. 510 Energy Procurement and Manufacturing 512 While an EnMS may be a central point for corporate 513 reporting, cost computation, environmental impact analysis, 514 and regulatory compliance reporting - Energy Management in 515 this framework excludes energy procurement and the 516 environmental impact of energy use. 518 As such the framework does not include: 519 o Cost in currency or environmental units of 520 manufacturing a device. 521 o Embedded carbon or environmental equivalences of a 522 device 524 o Cost in currency or environmental impact to dismantle 525 or recycle a device. 526 o Supply chain analysis of energy sources for device 527 deployment 528 o Conversion of the usage or production of energy to 529 units expressed from the source of that energy (such 530 as the greenhouse gas emissions associated the 531 transfer of energy from a diesel source). 533 6. Energy Management Abstraction 535 This section describes a conceptual model of information 536 that can be used for Energy Management. The classes and 537 categories of attributes in the model are described with 538 rationale for each. 540 6.1. Conceptual Model 542 This section describes an information model that addresses 543 issues specific to Energy Management, which complements 544 existing Network Management models. 546 An information model for Energy Management will need to 547 describe a means to monitor and control devices and 548 components. The model will also need to describe the 549 relationships among and connections between devices and 550 components. 552 This section defines a similar conceptual model for devices 553 and components to that used in Network Management: devices, 554 components, and interfaces. This section then defines the 555 additional attributes specific to Energy Management for 556 those entities that are not available in existing Network 557 Management models. 559 For modeling the devices and components this section 560 describes three classes denoted by a "(Class)" suffix: a 561 Device (Class), a Component (Class), and a Power Interface 562 (Class). These classes are sub-types of an abstract Energy 563 Object (Class). 565 Summary of Notation for Modeling Physical Equipment 567 Physical Modeling (Meta Data) Model Instance 568 --------------------------------------------------------- 569 equipment Energy Object (Class) Energy Object 570 device Device (Class) Device 571 component Component (Class) Component 572 inlet / outlet Power Interface (Class) Power Interface 573 This section then describes the attributes of an Energy 574 Object (Class) for identification, classification, context, 575 control, power and energy. 577 Since the interconnections between devices and components 578 for Energy Management may have no relation to the 579 interconnections for Network Management the Energy Object 580 (Classes) contain a separate Relationships (Class) as an 581 attribute to model these types of interconnections. 583 The next sections describe the each of the classes and 584 categories of attributes in the information model. 586 Not all of the attributes are mandatory for 587 implementations. Specifications describing implementations 588 of the information model in this framework need to be 589 explicit about which are mandatory and which are optional 590 to implement 592 The formal definitions of the classes and attributes are 593 specified in Section 7. 595 6.2. Energy Object (Class) 597 An Energy Object (Class) represents a piece of equipment 598 that is part of, or attached to, a communications network 599 which is monitored, controlled, or aids in the management 600 of another device for Energy Management. 602 The Energy Object (Class) is an abstract class that 603 contains the base attributes to represent a piece of 604 equipment for Energy Management. There are three types of 605 Energy Object (Class): Device (Class), Component (Class) 606 and Power Interface (Class). 608 6.2.1. Device (Class) 610 The Device (Class) is a sub-class of Energy Object (Class) 611 that represents a physical piece of equipment. 613 A Device (Class) instance represents a device that is a 614 consumer, producer, meter, distributor, or store of energy. 616 A Device (Class) instance may represent a physical device 617 that contains other components. 619 6.2.2. Component (Class) 621 The Component (Class) is a sub-class of Energy Object 622 (Class) that represents a part of a physical piece of 623 equipment. 625 6.2.3. Power Interface (Class) 627 A Power Interface (Class) represents the interconnections 628 (inlet, outlet) among devices or components where energy 629 can be provided, received, or both. 631 The Power Interface (Class) is a sub-class of Energy Object 632 (Class) that represents a physical inlet or outlet. 634 There are some similarities between Power Interfaces and 635 network interfaces. A network interface can be set to 636 different states, such as sending or receiving data on an 637 attached line. Similarly, a Power Interface can be 638 receiving or providing energy. 640 A Power Interface (Class) instance can represent 641 (physically) an AC power socket, an AC power cord attached 642 to a device, or an 8P8C (RJ45) PoE socket, etc. 644 6.3. Energy Object Attributes 646 This section describes categories of attributes for an 647 Energy Object (Class). 649 6.3.1. Identification 651 A Universal Unique Identifier (UUID) [RFC4122] is used to 652 uniquely and persistently identify an Energy Object. 654 Every Energy Object has an optional unique human readable 655 printable name. Possible naming conventions are: textual 656 DNS name, MAC address of the device, interface ifName, or a 657 text string uniquely identifying the Energy Object. As an 658 example, in the case of IP phones, the Energy Object name 659 can be the device's DNS name. 661 Additionally an alternate key is provided to allow an 662 Energy Object to be optionally linked with models in 663 different systems. 665 6.3.2. Context: General 666 In order to aid in reporting and in differentiation between 667 Energy Objects, each object optionally contains information 668 establishing its business, site, or organizational context 669 within a deployment. 671 The Energy Object (Class) contains a category attribute 672 that broadly describes how an instance is used in a 673 deployment. The category indicates if the Energy Object is 674 primarily functioning as a consumer, producer, meter, 675 distributor or store of energy. 677 Given the category and context of an object, an EnMS can 678 summarize or analyze measurements for the site. 680 6.3.3. Context: Importance 682 An Energy Object can provide an importance value in the 683 range of 1 to 100 to help rank a device's use or relative 684 value to the site. The importance range is from 1 (least 685 important) to 100 (most important). The default importance 686 value is 1. 688 For example: A typical office environment has several types 689 of phones, which can be rated according to their business 690 impact. A public desk phone has a lower importance (for 691 example, 10) than a business-critical emergency phone (for 692 example, 100). As another example: A company can consider 693 that a PC and a phone for a customer-service engineer are 694 more important than a PC and a phone for lobby use. 696 Although EnMS and administrators can establish their own 697 ranking, the following example is a broad recommendation 698 for commercial deployments [CISCO-EW]: 700 90 to 100 Emergency response 701 80 to 90 Executive or business-critical 702 70 to 79 General or Average 703 60 to 69 Staff or support 704 40 to 59 Public or guest 705 1 to 39 Decorative or hospitality 707 6.3.4. Context: Keywords 709 The Energy Object (Class) contains an attribute with 710 context keywords. 712 An Energy Object can provide a set of keywords that are a 713 list of tags that can be used for grouping, for summary 714 reporting (within or between Energy Management Domains), 715 and for searching. All alphanumeric characters and symbols 716 (other than a comma), such as "R&D", are allowed. White 717 spaces before and after the commas are ignored, as well as 718 within a keyword itself. Alphanumeric and symbol 719 characters from the entire Unicode repertoire are expected 720 to be reasonable. Potential examples are: IT, lobby, 721 HumanResources, Accounting, StoreRoom, CustomerSpace, 722 router, phone, floor2, or SoftwareLab. 724 There is no default value for a keyword. Multiple keywords 725 can be assigned to an Energy Object. White spaces before 726 and after the commas are excluded, as well as within a 727 keyword itself. In such cases, commas separate the keywords 728 and no spaces between keywords are allowed. For example, 729 "HR,Bldg1,Private". 731 6.3.5. Context: Role 733 The Energy Object (Class) contains a role attribute. The 734 "role description" string indicates the primary purpose the 735 Energy Object serves in the deployment. This could be a 736 string representing the purpose the Energy Object fulfills 737 in the deployment. 739 Administrators can define any naming scheme for the role. 740 As guidance, a two-word role that combines the service the 741 Energy Object provides along with type can be used 742 [IPENERGY]. 744 Alphanumeric characters from the entire Unicode repertoire 745 are expected to be reasonable. 747 Example types of devices: Router, Switch, Light, Phone, 748 WorkStation, Server, Display, Kiosk, HVAC. 750 Example Services by Line of Business: 752 Line of Business Service 753 ----------------------------------------------------- 754 Education Student, Faculty, 755 Administration, 756 Athletic 757 Finance Trader, Teller, Fulfillment 758 Manufacturing Assembly, Control, Shipping 759 Retail Advertising, Cashier 760 Support Helpdesk, Management 761 Medical Patient, Administration, Billing 763 Role as a two-word string: "Faculty Desktop", "Teller 764 Phone", "Shipping HVAC", "Advertising Display", "Helpdesk 765 Kiosk", "Administration Switch". 767 6.3.6. Context: Domain 769 The Energy Object (Class) contains a string attribute to 770 indicate membership in an Energy Management Domain. An 771 Energy Management Domain can be any collection of Energy 772 Objects in a deployment, but it is recommended to map 1:1 773 with a metered or sub-metered portion of the site. 775 Alphanumeric characters from the entire Unicode repertoire 776 are expected to be reasonable. 778 In building management, a meter refers to the meter 779 provided by the utility used for billing and measuring 780 power to an entire building or unit within a building. A 781 sub-meter refers to a customer- or user-installed meter 782 that is not used by the utility to bill but is instead used 783 to get measurements from sub portions of a building. 785 An Energy Object MUST be a member of a single Energy 786 Management Domain therefore one attribute is provided. 788 6.4. Measurements 790 The Energy Object (Class) contains attributes to describe 791 power, energy and demand measurements. 793 An analogy for understanding power versus energy 794 measurements can be made to speed and distance in 795 automobiles. Just as a speedometer indicates the rate of 796 change of distance (speed), a power measurement indicates 797 the rate of transfer of energy. The odometer in an 798 automobile measures the cumulative distance traveled and 799 similarly an energy measurement indicates the accumulated 800 energy transferred. 802 Demand measurements are averages of power measurements over 803 time. So using the same analogy to an automobile: measuring 804 the average vehicle speed over multiple intervals of time 805 for a given distance travelled, demand is the average power 806 measured over multiple time intervals for a given energy 807 value. 809 Within this framework, energy will only be quantified in 810 units of watt-hours. Physical devices measuring energy in 811 other units must convert values to watt-hours or be 812 represented by Energy Objects that convert to watt-hours. 814 6.4.1. Measurements: Power 816 The Energy Object (Class) contains a Nameplate Power 817 attribute that describes the nominal power as specified by 818 the manufacturer of the device. The EnMS can use the 819 Nameplate Power for provisioning, capacity planning and 820 (potentially) billing. 822 The Energy Object (Class) has attributes that describe the 823 present power information, along with how that measurement 824 was obtained or derived (e.g., actual, estimated, or 825 static). 827 A power measurement is qualified with the units, magnitude 828 and direction of power flow, and is qualified as to the 829 means by which the measurement was made. 831 Power measurement magnitude conforms to the [IEC61850] 832 definition of unit multiplier for the SI (System 833 International) units of measure. Measured values are 834 represented in SI units obtained by BaseValue * (10 ^ 835 Scale). For example, if current power usage of an Energy 836 Object is 17, it could be 17 W, 17 mW, 17 kW, or 17 mW, 837 depending on the value of the scaling factor. 17 W implies 838 that the BaseValue is 17 and Scale = 0, whereas 17 mW 839 implies BaseValue = 17 and ScaleFactor = -3. 841 An Energy Object (Class) indicates how the power 842 measurement was obtained with a caliber and accuracy 843 attribute that indicates: 844 o Whether the measurements were made at the device 845 itself or at a remote source. 846 o Description of the method that was used to measure 847 the power and whether this method can distinguish 848 actual or estimated values. 849 o Accuracy for actual measured values 851 6.4.2. Measurements: Power Attributes 853 The Energy Object (Class) contains an optional attribute 854 that describes Power Attribute information reflecting the 855 electrical characteristics of the measurement. These Power 856 Attributes adhere to the [IEC61850-7-2] standard for 857 describing AC measurements. 859 6.4.3. Measurements: Energy 861 The Energy Object (Class) contains optional attributes that 862 represent the energy used, received, produced and or 863 stored. Typically only devices or components that can 864 measure actual power will have the ability to measure 865 energy. 867 6.4.4. Measurements: Demand 869 The Energy Object (Class) contains optional attributes that 870 represent demand information over time. Typically only 871 devices or components that can report actual power are 872 capable of measuring demand. 874 6.5. Control 876 The Energy Object (Class) contains a Power State Set 877 (Class) attribute that represents the set of Power States a 878 device or component supports. 880 A Power State describes a condition or mode of a device or 881 component. While Power States are typically used for 882 control they may be used for monitoring only. 884 A device or component is expected to support at least one 885 set of Power States consisting of at least two states, an 886 on state and an off state. 888 There are many existing standards describing device and 889 component Power States. The framework supports modeling a 890 mixed set of Power States defined in different standards. A 891 basic example is given by the three Power States defined in 892 IEEE1621 [IEEE1621]: on, off, and sleep. The DMTF [DMTF], 893 ACPI [ACPI], and Printer Working Group (PWG) all define 894 larger numbers of Power States. 896 The semantics of a Power State are specified by 897 a) the functionality provided by an Energy Object in 898 this state, 899 b) a limitation of the power that an Energy Object uses 900 in this state, 901 c) a combination of a) and b) 903 The semantics of a Power State should be clearly defined. 904 Limitation (curtailment) of the power used by an Energy 905 Object in a state may be specified by: 906 o an absolute power value 907 o a percentage value of power relative to the energy 908 object's nameplate power 909 o an indication of power relative to another power 910 state. For example: Specify that power in state A is 911 less than in state B. 912 o For supporting Power State management an Energy 913 Object provides statistics on Power States including 914 the time an Energy Object spent in a certain Power 915 State and the number of times an Energy Object 916 entered a power state. 918 When requesting an Energy Object to enter a Power State an 919 indication of the Power State's name or number can be used. 920 Optionally an absolute or percentage of Nameplate Power can 921 be provided to allow the Energy Object to transition to a 922 nearest or equivalent Power State. 924 When an Energy Object is set to a particular Power State, 925 the represented device or component may be busy. The Energy 926 Object should set the desired Power State and then update 927 the actual Power State when the device or component 928 changes. There are then two Power State (Class) control 929 attributes: actual and requested. 931 The following sections describe well-known Power States for 932 devices and components that should be modeled in the 933 information model. 935 6.5.1. Power State Sets 937 There are several standards and implementations of Power 938 State Sets. The Energy Object (Class) support modeling one 939 or multiple Power State Set implementation(s) on the device 940 or component concurrently. 942 There are currently three Power State Sets advocated: 943 IEEE1621(256) - [IEEE1621] 944 DMTF(512) - [DMTF] 945 EMAN(768) - [this document] 947 The respective specific states related to each Power State 948 Set are specified in the following sections. The guidelines 949 for the modification of Power State Sets are specified in 950 the IANA Considerations Section. 952 6.5.2. Power State Set: IEEE1621 954 The IEEE1621 Power State Set [IEEE1621] consists of 3 955 rudimentary states: on, off or sleep. 957 In IEEE1621 devices are limited to the three basic power 958 states - on (2), sleep (1), and off (0). Any additional 959 power states are variants of one of the basic states rather 960 than a fourth state [IEEE1621]. 962 6.5.3. Power State Set: DMTF 964 The DMTF [DMTF] standards organization has defined a power 965 profile standard based on the CIM (Common Information 966 Model) model that consists of 15 power states: 968 {ON (2), SleepLight (3), SleepDeep (4), Off-Hard (5), Off- 969 Soft (6), Hibernate(7), PowerCycle Off-Soft (8), PowerCycle 970 Off-Hard (9), MasterBus reset (10), Diagnostic Interrupt 971 (11), Off-Soft-Graceful (12), Off-Hard Graceful (13), 972 MasterBus reset Graceful (14), Power-Cycle Off-Soft 973 Graceful (15), PowerCycle-Hard Graceful (16)} 975 The DMTF standard is targeted for hosts and computers. 976 Details of the semantics of each Power State within the 977 DMTF Power State Set can be obtained from the DMTF Power 978 State Management Profile specification [DMTF]. 980 The DMTF power profile extends ACPI power states. The 981 following table provides a mapping between DMTF and ACPI 982 Power State Set: 984 DMTF ACPI 985 Reserved (0) 986 Reserved (1) 987 ON (2) G0-S0 988 Sleep-Light (3) G1-S1 G1-S2 989 Sleep-Deep (4) G1-S3 990 Power Cycle (Off-Soft) (5) G2-S5 991 Off-hard (6) G3 992 Hibernate (Off-Soft) (7) G1-S4 993 Off-Soft (8) G2-S5 994 Power Cycle (Off-Hard) (9) G3 995 Master Bus Reset (10) G2-S5 996 Diagnostic Interrupt (11) G2-S5 997 Off-Soft Graceful (12) G2-S5 998 Off-Hard Graceful (13) G3 999 MasterBus Reset Graceful (14) G2-S5 1000 Power Cycle off-soft Graceful (15) G2-S5 1001 Power Cycle off-hard Graceful (16) G3 1003 6.5.4. Power State Set: IETF EMAN 1004 The EMAN Power States are an expansion of the basic Power 1005 States as defined in [IEEE1621] that also incorporates the 1006 Power States defined in [ACPI] and [DMTF]. Therefore, in 1007 addition to the non-operational states as defined in [ACPI] 1008 and [DMTF] standards, several intermediate operational 1009 states have been defined. 1011 Physical devices and components are expected to support the 1012 EMAN Power State Set or to be modeled via an Energy Object 1013 the supports these states. 1015 An Energy Object may implement fewer or more Power States 1016 than a particular EMAN Power State Set specifies. In that 1017 case, the Energy Object implementation can determine its 1018 own mapping to the predefined EMAN Power States within the 1019 EMAN Power State Set. 1021 There are twelve EMAN Power States that expand on 1022 [IEEE1621]. The expanded list of Power States is derived 1023 from [CISCO-EW] and is divided into six operational states 1024 and six non-operational states. 1026 The lowest non-operational state is 1 and the highest is 6. 1027 Each non-operational state corresponds to an [ACPI] Global 1028 and System state between G3 (hard-off) and G1 (sleeping). 1029 Each operational state represents a performance state, and 1030 may be mapped to [ACPI] states P0 (maximum performance 1031 power) through P5 (minimum performance and minimum power). 1033 In each of the non-operational states (from mechoff(0) to 1034 ready(5)), the Power State preceding it is expected to have 1035 a lower Power value and a longer delay in returning to an 1036 operational state: 1038 mechoff(0) : An off state where no Energy Object 1039 features are available. The Energy Object is unavailable. 1040 No energy is being consumed and the power connector can be 1041 removed. 1043 softoff(1) : Similar to mechoff(0), but some 1044 components remain powered or receive trace power so that 1045 the Energy Object can be awakened from its off state. In 1046 softoff(1), no context is saved and the device typically 1047 requires a complete boot when awakened. 1049 hibernate(2): No Energy Object features are 1050 available. The Energy Object may be awakened without 1051 requiring a complete boot, but the time for availability is 1052 longer than sleep(3). An example for state hibernate(2) is 1053 a save to-disk state where DRAM context is not maintained. 1054 Typically, energy consumption is zero or close to zero. 1056 sleep(3) : No Energy Object features are 1057 available, except for out-of-band management, such as wake- 1058 up mechanisms. The time for availability is longer than 1059 standby(4). An example for state sleep(3) is a save-to-RAM 1060 state, where DRAM context is maintained. Typically, energy 1061 consumption is close to zero. 1063 standby(4) : No Energy Object features are 1064 available, except for out-of-band management, such as wake- 1065 up mechanisms. This mode is analogous to cold-standby. 1066 The time for availability is longer than ready(5). For 1067 example processor context is may not be maintained. 1068 Typically, energy consumption is close to zero. 1070 ready(5) : No Energy Object features are 1071 available, except for out-of-band management, such as wake- 1072 up mechanisms. This mode is analogous to hot-standby. The 1073 Energy Object can be quickly transitioned into an 1074 operational state. For example, processors are not 1075 executing, but processor context is maintained. 1077 lowMinus(6) : Indicates some Energy Object 1078 features may not be available and the Energy Object has 1079 taken measures or selected options to use less energy than 1080 low(7). 1082 low(7) : Indicates some features may not be 1083 available and the Energy Object has taken measures or 1084 selected options to use less energy than mediumMinus(8). 1086 mediumMinus(8): Indicates all Energy Object 1087 features are available but the Energy Object has taken 1088 measures or selected options to use less energy than 1089 medium(9). 1091 medium(9) : Indicates all Energy Object features 1092 are available but the Energy Object has taken measures or 1093 selected options to use less energy than highMinus(10). 1095 highMinus(10): Indicates all Energy Object 1096 features are available and has taken measures or selected 1097 options to use less energy than high(11). 1099 high(11) : Indicates all Energy Object features 1100 are available and the Energy Object may use the maximum 1101 energy as indicated by the Nameplate Power. 1103 6.5.5. Power State Sets Comparison 1105 A comparison of Power States from different Power State 1106 Sets can be seen in the following table: 1107 IEEE1621 DMTF ACPI EMAN 1109 Non-operational states 1110 off Off-Hard G3, S5 mechoff(0) 1111 off Off-Soft G2, S5 softoff(1) 1112 off Hibernate G1, S4 hibernate(2) 1113 sleep Sleep-Deep G1, S3 sleep(3) 1114 sleep Sleep-Light G1, S2 standby(4) 1115 sleep Sleep-Light G1, S1 ready(5) 1117 Operational states: 1118 on on G0, S0, P5 lowMinus(6) 1119 on on G0, S0, P4 low(7) 1120 on on G0, S0, P3 mediumMinus(8) 1121 on on G0, S0, P2 medium(9) 1122 on on G0, S0, P1 highMinus(10) 1123 on on G0, S0, P0 high(11) 1125 6.6. Relationships 1127 The Energy Object (Class) contains a set of Relationship 1128 (Class) attributes to model the relationships between 1129 devices and components. Two Energy Objects can establish 1130 an Energy Object Relationship to model the deployment 1131 topology with respect to Energy Management. 1133 Relationships are modeled with a Relationship (Class) that 1134 contains the UUID of the other participant in the 1135 relationship and a name that describes the type of 1136 relationship [CHEN]. The types of relationships are: Power 1137 Source, Metering, and Aggregations. 1139 o A Power Source Relationship is relationship where one 1140 Energy Object provides power to one or more Energy 1141 Objects. The Power Source Relationship gives a view 1142 of the physical wiring topology. For example: a data 1143 center server receiving power from two specific Power 1144 Interfaces from two different PDUs. 1146 Note: A Power Source Relationship may or may not 1147 change as the direction of power changes between two 1148 Energy Objects. The relationship may remain to 1149 indicate the change of power direction was unintended 1150 or an error condition. 1152 o A Metering Relationship is relationship where one 1153 Energy Object measures power, energy, demand or Power 1154 Attributes of one or more other Energy Objects. The 1155 Metering Relationship gives the view of the metering 1156 topology. Physical meters can be placed anywhere in 1157 a power distribution tree. For example, utility 1158 meters monitor and report accumulated power 1159 consumption of the entire building. Logically, the 1160 metering topology overlaps with the wiring topology, 1161 as meters are connected to the wiring topology. A 1162 typical example is meters that clamp onto the 1163 existing wiring. 1165 o An Aggregation Relationship is a relationship where 1166 one Energy Object aggregates Energy Management 1167 information of one or more other Energy Objects. The 1168 Aggregation Relationship gives a model of devices 1169 that may aggregate (sum, average, etc) values for 1170 other devices. The Aggregation Relationship is 1171 slightly different compared to the other 1172 relationships as this refers more to a management 1173 function. 1175 In some situations, it is not possible to discover the 1176 Energy Object relationships, and an EnMS or administrator 1177 must set them. Given that relationships can be assigned 1178 manually, the following sections describe guidelines for 1179 use. 1181 6.6.1. Relationship Conventions and Guidelines 1183 This Energy Management framework does not impose many 1184 "MUST" rules related to Energy Object Relationships. There 1185 are always corner cases that could be excluded with too 1186 strict specifications of relationships. However, the 1187 framework proposes a series of guidelines, indicated with 1188 "SHOULD" and "MAY". 1190 6.6.2. Guidelines: Power Source 1192 Power Source relationships are intended to identify the 1193 connections between Power Interfaces. This is analogous to 1194 a Layer 2 connection in networking devices (a "one-hop 1195 connection"). 1197 The preferred modeling would be for Power Interfaces to 1198 participate in Power Source Relationships. It some cases 1199 Energy Objects may not have the capability to model Power 1200 Interfaces. Therefore a Power Source Relationship can be 1201 established between two Energy Objects or two non-connected 1202 Power Interfaces. 1204 While strictly speaking Components and Power Interfaces on 1205 the same Device do provide or receive energy from each 1206 other, the Power Source relationship is intended to show 1207 energy transfer between Devices. Therefore the relationship 1208 is implied when on the same Device. 1210 An Energy Object SHOULD NOT establish a Power Source 1211 Relationship with a Component. 1212 o A Power Source Relationship SHOULD be established 1213 with the next known Power Interface in the wiring 1214 topology. 1216 o The next known Power Interface in the wiring topology 1217 would be the next device implementing the framework. 1218 In some cases the domain of devices under management 1219 may include some devices that do not implement the 1220 framework. In these cases, the Power Source 1221 relationship can be established with the next device 1222 in the topology that implements the framework and 1223 logically shows the Power Source of the device. 1225 o Transitive Power Source relationships SHOULD NOT be 1226 established. For example, if an Energy Object A has 1227 a Power Source Relationship "Poweredby" with the 1228 Energy Object B, and if the Energy Object B has a 1229 Power Source Relationship "Poweredby" with the Energy 1230 Object C, then the Energy Object A SHOULD NOT have a 1231 Power Source Relationship "Poweredby" with the Energy 1232 Object C. 1234 6.6.3. Guidelines: Metering Relationship 1236 Metering Relationships are intended to show when one device 1237 acting as a meter is measuring the power or energy at a 1238 point in a power distribution system. Since one point of a 1239 power distribution system may cover many devices within a 1240 wiring topology, this relationship type can be seen as a 1241 set. 1243 Some devices, however, may include measuring hardware for 1244 components, and outlets or for the entire device. For 1245 example, some PDUs may have the ability to measure power 1246 for each outlet and are commonly referred to as metered-by- 1247 outlet. Others may be able to control power at each power 1248 outlet but can only measure power at the power inlet - 1249 commonly referred to as metered-by-device. 1251 While the Metering Relationship could be used to represent 1252 a device as metered-by-outlet or metered-by-device, the 1253 Metering Relationship SHOULD be used to model the 1254 relationship between a meter and all devices covered by the 1255 meter downstream in the power distribution system 1257 In general: 1258 o A Metering Relationship MAY be established with any 1259 other Energy Object, Component, or Power Interface. 1261 o Transitive Metering Relationships MAY be used. 1263 o When there is a series of meters for one Energy 1264 Object, the Energy Object MAY establish a Metering 1265 relationship with one or more of the meters. 1267 6.6.4. Guidelines: Aggregation 1269 Aggregation relationships are intended to identify when one 1270 device is used to accumulate values from other devices. 1271 Typically this is for energy or power values among devices 1272 and not for Components or Power Interfaces on the same 1273 device. 1275 The intent of Aggregation relationships is to indicate when 1276 one device is providing aggregate values for a set of other 1277 devices when it is not obvious from the power source or 1278 simple containment within a device. 1280 Establishing aggregation relationships within the same 1281 device would make modeling more complex and the aggregated 1282 values can be implied from the use of Power Inlets, outlet 1283 and Energy Object values on the same device. 1285 Since an EnMS is naturally a point of aggregation it is not 1286 necessary to model aggregation for Energy Management 1287 Systems. 1289 The Aggregation Relationship is intended for power and 1290 energy. It MAY be used for aggregation of other values from 1291 the information model, but the rules and logical ability to 1292 aggregate each attribute is out of scope for this document. 1294 In general: 1296 o A Device SHOULD NOT establish an Aggregation 1297 Relationship with Components contained on the same 1298 device. 1299 o A Device SHOULD NOT establish an Aggregation 1300 Relationship with the Power Interfaces contained on 1301 the same device. 1302 o A Device SHOULD NOT establish an Aggregation 1303 Relationship with an EnMS. 1304 o Aggregators SHOULD log or provide notification in the 1305 case of errors or missing values while performing 1306 aggregation. 1308 6.6.5. Energy Object Relationship Extensions 1310 This framework for Energy Management is based on three 1311 relationship types: Aggregation , Metering, and Power 1312 Source. 1313 This framework is defined with possible future extension of 1314 new Energy Object Relationships in mind. 1315 For example: 1316 o Some Devices that may not be IP connected. This can 1317 be modeled with a proxy relationship to an Energy 1318 Object within the domain. This type of proxy 1319 relationship is left for further development. 1320 o A Power Distribution Unit (PDU) that allows devices 1321 and components like outlets to be "ganged" together 1322 as a logical entity for simplified management 1323 purposes, could be modeled with an extension called a 1324 "gang relationship", whose semantics would specify 1325 the Energy Objects' grouping. 1327 7. Energy Management Information Model 1329 This section presents an information model expression of 1330 the concepts in this framework as a reference for 1331 implementers. The information model is implemented as MIB 1332 modules in the different related IETF EMAN documents. 1333 However, other programming structures with different data 1334 models could be used as well. 1336 Data modeling specifications of this information model may 1337 where needed specify which attributes are required or 1338 optional. 1340 Syntax 1342 UML Construct 1343 [ISO-IEC-19501-2005] Equivalent Notation 1344 -------------------- ------------------------------------ 1345 Notes // Notes 1346 Class 1347 (Generalization) CLASS name {member..} 1348 Sub-Class 1349 (Specialization) CLASS subclass 1350 EXTENDS superclass {member..} 1351 Class Member 1352 (Attribute) attribute : type 1354 Model 1356 CLASS EnergyObject { 1358 // identification / classification 1359 index : int 1360 identifier : uuid 1361 alternatekey : string 1363 // context 1364 domainName : string 1365 role : string 1366 keywords [0..n] : string 1367 importance : int 1369 // relationship 1370 relationships [0..n] : Relationship 1372 // measurements 1373 nameplate : Nameplate 1374 power : PowerMeasurement 1375 energy : EnergyMeasurment 1376 demand : DemandMeasurement 1378 // control 1379 powerControl [0..n] : PowerStateSet 1380 } 1381 CLASS PowerInterface EXTENDS EnergyObject{ 1382 eoIfType : enum { inlet, outlet, both} 1383 } 1385 CLASS Device EXTENDS EnergyObject { 1386 eocategory : enum { producer, consumer, meter, 1387 distributor, store } 1388 powerInterfaces[0..n]: PowerInterface 1389 components [0..n] : Component 1390 } 1392 CLASS Component EXTENDS EnergyObject 1393 eocategory : enum { producer, consumer, meter, 1394 distributor, store } 1395 powerInterfaces[0..n]: PowerInterface 1396 components [0..n] : Component 1398 } 1400 CLASS Nameplate { 1401 nominalPower : PowerMeasurement 1402 details : URI 1403 } 1405 CLASS Relationship { 1406 relationshipType : enum { meters, meteredby, 1407 powers, poweredby, aggregates, aggregatedby } 1408 relationshipObject : uuid 1409 } 1411 CLASS Measurement { 1412 multiplier: enum { -24..24} 1413 caliber : enum { actual, estimated, static } 1414 accuracy : enum { 0..10000} // hundreds of percent 1415 } 1417 CLASS PowerMeasurement EXTENDS Measurement { 1418 value : long 1419 units : "W" 1420 powerAttribute : PowerAttribute 1421 } 1423 CLASS EnergyMeasurement EXTENDS Measurement { 1424 startTime : time 1425 units : "kWh" 1426 provided : long 1427 used : long 1428 produced : long 1429 stored : long 1431 } 1433 CLASS TimedMeasurement EXTENDS Measurement { 1434 startTime : timestamp 1435 value : Measurement 1436 maximum : Measurement 1437 } 1439 CLASS TimeInterval { 1440 value : long 1441 units : enum { seconds, miliseconds,...} 1442 } 1444 CLASS DemandMeasurement EXTENDS Measurement { 1445 intervalLength : TimeInterval 1446 intervals : long 1447 intervalMode : enum { periodic, sliding, total } 1448 intervalWindow : TimeInterval 1449 sampleRate : TimeInterval 1450 status : enum { active, inactive } 1451 measurements[0..n] : TimedMeasurements 1452 } 1454 CLASS PowerStateSet { 1455 powerSetIdentifier : int 1456 name : string 1457 powerStates [0..n] : PowerState 1458 operState : int 1459 adminState : int 1460 reason : string 1461 configuredTime : timestamp 1462 } 1464 CLASS PowerState { 1465 powerStateIdentifier : int 1466 name : string 1467 cardinality : int 1468 maximumPower : PowerMeasurement 1469 totalTimeInState : time 1470 entryCount : long 1471 } 1473 CLASS PowerAttribute { 1474 acQuality : ACQuality 1475 } 1477 CLASS ACQuality { 1478 acConfiguration : enum {SNGL, DEL,WYE} 1479 avgVoltage : long 1480 avgCurrent : long 1481 frequency : long 1482 unitMultiplier : int 1483 accuracy : int 1484 totalActivePower : long 1485 totalReactivePower : long 1486 totalApparentPower : long 1487 totalPowerFactor : long 1488 phases [0..2] : ACPhase 1489 } 1491 CLASS ACPhase { 1492 phaseIndex : long 1493 avgCurrent : long 1494 activePower : long 1495 reactivePower : long 1496 apparentPower : long 1497 powerFactor : long 1498 } 1500 CLASS DelPhase EXTENDS ACPhase { 1501 phaseToNextPhaseVoltage : long 1502 thdVoltage : long 1503 thdCurrent : long 1504 } 1506 CLASS WYEPhase EXTENDS ACPhase { 1507 phaseToNeutralVoltage : long 1508 thdCurrent : long 1509 thdVoltage : long 1510 } 1512 8. Modeling Relationships between Devices 1514 In this section we give examples of how to use the EMAN 1515 information model to model physical topologies. Where 1516 applicable, we show how the framework can be applied when 1517 devices can be modeled with Power Interfaces. We also show 1518 how the framework can be applied when devices cannot be 1519 modeled with Power Interfaces but only monitored or control 1520 as a whole. For instance, a PDU may only be able to measure 1521 power and energy for the entire unit without the ability to 1522 distinguish among the inlets or outlets. 1524 8.1. Power Source Relationship 1526 The Power Source relationship is used to model the 1527 interconnections between devices, components and/Power 1528 Interfaces to indicate the source of energy for a device. 1530 In the following examples we show variations on modeling 1531 the reference topologies using relationships. 1533 Given for all cases: 1535 Device W: A computer with one power supply. Power Interface 1536 1 is an inlet for Device W. 1538 Device X: A computer with two power supplies. Power 1539 Interface 1 and power interface 2 are both inlets for 1540 Device X. 1542 Device Y: A PDU with multiple Power Interfaces numbered 1543 0..10. Power Interface 0 is an inlet and Power Interface 1544 1..10 are outlets. 1546 Device Z: A PDU with multiple Power Interfaces numbered 1547 0..10. Power Interface 0 is an inlet and Power Interface 1548 1..10 are outlets. 1550 Case 1: Simple Device with one Source 1552 Physical Topology: 1554 o Device W inlet 1 is plugged into Device Y outlet 8. 1556 With Power Interfaces: 1558 o Device W has an Energy Object representing the 1559 computer itself as well as one Power Interface 1560 defined as an inlet. 1561 o Device Y would have an Energy Object representing the 1562 PDU itself (the Device), with a Power Interface 0 1563 defined as an inlet and Power Interfaces 1..10 1564 defined as outlets. 1566 The interfaces of the devices would have a Power Source 1567 Relationship such that: 1568 Device W inlet 1 is powered by Device Y outlet 8. 1570 +-------+------+ poweredBy +------+----------+ 1571 | PDU Y | PI 8 |-----------------| PI 1 | Device W | 1572 +-------+------+ powers +------+----------+ 1574 Without Power Interfaces: 1576 o Device W has an Energy Object representing the 1577 computer. 1579 o Device Y would have an Energy Object representing the 1580 PDU. 1582 The devices would have a Power Source Relationship such 1583 that: 1584 Device W is powered by Device Y. 1586 +----------+ poweredBy +------------+ 1587 | PDU Y |-----------------| Device W | 1588 +----------+ powers +------------+ 1590 Case 2: Multiple Inlets 1592 Physical Topology: 1593 o Device X inlet 1 is plugged into Device Y outlet 8. 1594 o Device X inlet 2 is plugged into Device Y outlet 9. 1596 With Power Interfaces: 1598 o Device X has an Energy Object representing the 1599 computer itself. It contains two Power Interfaces 1600 defined as inlets. 1601 o Device Y would have an Energy Object representing the 1602 PDU itself (the Device), with a Power Interface 0 1603 defined as an inlet and Power Interfaces 1..10 1604 defined as outlets. 1606 The interfaces of the devices would have a Power Source 1607 Relationship such that: 1608 Device X inlet 1 is powered by Device Y outlet 8. 1609 Device X inlet 2 is powered by Device Y outlet 9. 1611 +-------+------+ poweredBy+------+----------+ 1612 | | PI 8 |-----------------| PI 1 | | 1613 | | |powers | | | 1614 | PDU Y +------+ poweredBy+------+ Device X | 1615 | | PI 9 |-----------------| PI 2 | | 1616 | | |powers | | | 1617 +-------+------+ +------+----------+ 1619 Without Power Interfaces: 1621 o Device X has an Energy Object representing the 1622 computer. Device Y has an Energy Object representing 1623 the PDU. 1625 The devices would have a Power Source Relationship such 1626 that: 1627 Device X is powered by Device Y. 1629 +----------+ poweredBy +------------+ 1630 | PDU Y |-----------------| Device X | 1631 +----------+ powers +------------+ 1633 Case 3: Multiple Sources 1635 Physical Topology: 1636 o Device X inlet 1 is plugged into Device Y outlet 8. 1637 o Device X inlet 2 is plugged into Device Z outlet 9. 1639 With Power Interfaces: 1641 o Device X has an Energy Object representing the 1642 computer itself. It contains two Power Interface 1643 defined as inlets. 1644 o Device Y would have an Energy Object representing the 1645 PDU itself (the Device), with a Power Interface 0 1646 defined as an inlet and Power Interfaces 1..10 1647 defined as outlets. 1648 o Device Z would have an Energy Object representing the 1649 PDU itself (the Device), with a Power Interface 0 1650 defined as an inlet and Power Interfaces 1..10 1651 defined as outlets. 1653 The interfaces of the devices would have a Power Source 1654 Relationship such that: 1655 Device X inlet 1 is powered by Device Y outlet 8. 1656 Device X inlet 2 is powered by Device Z outlet 9. 1658 +-------+------+ poweredBy+------+----------+ 1659 | PDU Y | PI 8 |-----------------| PI 1 | | 1660 | | |powers | | | 1661 +-------+------+ +------+ | 1662 | Device X | 1663 +-------+------+ poweredBy+------+ | 1664 | PDU Z | PI 9 |-----------------| PI 2 | | 1665 | | |powers | | | 1666 +-------+------+ +------+----------+ 1668 Without Power Interfaces: 1670 o Device X has an Energy Object representing the 1671 computer. Device Y and Z would both have respective 1672 Energy Objects representing each entire PDU. 1674 The devices would have a Power Source Relationship such 1675 that: 1676 Device X is powered by Device Y and powered by Device Z. 1678 +----------+ poweredBy +------------+ 1679 | PDU Y |---------------------| Device X | 1680 +----------+ powers +------------+ 1682 +----------+ poweredBy +------------+ 1683 | PDU Z |---------------------| Device X | 1684 +----------+ powers +------------+ 1686 8.2. Metering Relationship 1688 A meter in a power distribution system can logically 1689 measure the power or energy for all devices downstream from 1690 the meter in the power distribution system. As such, a 1691 Metering relationship can be seen as a relationship between 1692 a meter and all of the devices downstream from the meter. 1694 We define in this case a Metering relationship between a 1695 meter and devices downstream from the meter. 1697 +-----+---+ meteredBy +--------+ poweredBy +-------+ 1698 |Meter| PI|--------------| switch |-------------| phone | 1699 +-----+---+ meters +--------+ powers +-------+ 1700 | | 1701 | meteredBy | 1702 +-------------------------------------------+ 1703 meters 1705 In cases where the Power Source topology cannot be 1706 discovered or derived from the information available in the 1707 Energy Management Domain, the metering topology can be used 1708 to relate the upstream meter to the downstream devices in 1709 the absence of specific Power Source relationships. 1711 A Metering Relationship can occur between devices that are 1712 not directly connected, as shown in the following figure: 1714 +---------------+ 1715 | Device 1 | 1716 +---------------+ 1717 | PI | 1718 +---------------+ 1719 | 1720 +---------------+ 1721 | Meter | 1722 +---------------+ 1723 . 1724 . 1725 . 1726 meters meters meters 1727 +----------+ +----------+ +-----------+ 1728 | Device A | | Device B | | Device C | 1729 +----------+ +----------+ +-----------+ 1731 An analogy to communications networks would be modeling 1732 connections between servers (meters) and clients (devices) 1733 when the complete Layer 2 topology between the servers and 1734 clients is not known. 1736 8.3. Aggregation Relationship 1738 Some devices can act as aggregation points for other 1739 devices. For example, a PDU controller device may contain 1740 the summation of power and energy readings for many PDU 1741 devices. The PDU controller will have aggregate values for 1742 power and energy for a group of PDU devices. 1744 This aggregation is independent of the physical power or 1745 communication topology. 1747 The functions that the aggregation point may perform 1748 include the calculation of values such as average, count, 1749 maximum, median, minimum, or the listing (collection) of 1750 the aggregation values, etc. 1751 Based on the experience gained on aggregations at the IETF 1752 [RFC7015], the aggregation function in the EMAN framework 1753 is limited to the summation. 1755 When aggregation occurs across a set of entities, values to 1756 be aggregated may be missing for some entities. The EMAN 1757 framework does not specify how these should be treated, as 1758 different implementations may have good reason to take 1759 different approaches. One common treatment is to define 1760 the aggregation as missing if any of the constituent 1761 elements are missing (useful to be most precise). Another 1762 is to treat the missing value as zero (useful to have 1763 continuous data streams). 1765 The specifications of aggregation functions are out of 1766 scope of the EMAN framework, but must be clearly specified 1767 by the equipment vendor. 1769 9. Relationship to Other Standards 1771 This Energy Management framework uses, as much as possible, 1772 existing standards especially with respect to information 1773 modeling and data modeling [RFC3444]. 1775 The data model for power- and energy-related objects is 1776 based on [IEC61850]. 1778 Specific examples include: 1779 o The scaling factor, which represents Energy Object 1780 usage magnitude, conforms to the [IEC61850] 1781 definition of unit multiplier for the SI (System 1782 International) units of measure. 1783 o The electrical characteristic is based on the ANSI 1784 and IEC Standards, which require that we use an 1785 accuracy class for power measurement. ANSI and IEC 1786 define the following accuracy classes for power 1787 measurement: 1788 o IEC 62053-22 60044-1 class 0.1, 0.2, 0.5, 1 3. 1789 o ANSI C12.20 class 0.2, 0.5 1790 o The electrical characteristics and quality adhere 1791 closely to the [IEC61850-7-4] standard for describing 1792 AC measurements. 1793 o The power state definitions are based on the DMTF 1794 Power State Profile and ACPI models, with operational 1795 state extensions. 1797 10. Implementation Status 1799 RFC Editor Note: Please remove this section and the 1800 reference to [RFC6982] before publication. 1802 This section records the status of known implementations of 1803 the protocol defined by this specification at the time of 1804 posting of this Internet-Draft, and is based on a proposal 1805 described in [RFC6982]. The description of implementations 1806 in this section is intended to assist the IETF in its 1807 decision processes in progressing drafts to RFCs. Please 1808 note that the listing of any individual implementation here 1809 does not imply endorsement by the IETF. Furthermore, no 1810 effort has been spent to verify the information presented 1811 here that was supplied by IETF contributors. This is not 1812 intended as, and must not be construed to be, a catalog of 1813 available implementations or their features. Readers are 1814 advised to note that other implementations may exist. 1816 According to RFC 6982, "this will allow reviewers and 1817 working groups to assign due consideration to documents 1818 that have the benefit of running code, which may serve as 1819 evidence of valuable experimentation and feedback that have 1820 made the implemented protocols more mature. 1822 Implementation descriptions for this document are 1823 maintained at: 1824 http://tools.ietf.org/wg/eman/trac/wiki/EmanImplementations 1826 11. Security Considerations 1828 Regarding the data attributes specified here, some or all 1829 may be considered sensitive or vulnerable in some network 1830 environments. Reading or writing these attributes without 1831 proper protection such as encryption or access 1832 authorization will have negative effects on network 1833 capabilities. Event logs for audit purposes on 1834 configuration and other changes should be generated 1835 according to current authorization, audit, and accounting 1836 principles to facilitate investigations (compromise or 1837 benign mis-configurations) or any reporting requirements. 1839 The information and control capabilities specified in this 1840 framework could be exploited with detriment to a site or 1841 deployment. Implementers of the framework SHOULD examine 1842 and mitigate security threats with respect to these new 1843 capabilities. 1845 [RFC3410] User Security Model for SNMPv3 presents a good 1846 description of threats and mitigations for the SNMPv3 1847 protocol that can be used as a guide for implementations of 1848 this framework using other protocols. 1850 11.1. Security Considerations for SNMP 1852 Readable objects in MIB modules (i.e., objects with a MAX- 1853 ACCESS other than not-accessible) may be considered 1854 sensitive or vulnerable in some network environments. It 1855 is important to control GET and/or NOTIFY access to these 1856 objects and possibly to encrypt the values of these objects 1857 when sending them over the network via SNMP. 1859 The support for SET operations in a non-secure environment 1860 without proper protection can have a negative effect on 1861 network operations. 1863 For example: 1864 o Unauthorized changes to the Energy Management Domain 1865 or business context of a device will result in 1866 misreporting or interruption of power. 1867 o Unauthorized changes to a power state will disrupt 1868 the power settings of the different devices, and 1869 therefore the state of functionality of the 1870 respective devices. 1871 o Unauthorized changes to the demand history will 1872 disrupt proper accounting of energy usage. 1874 With respect to data transport, SNMP versions prior to 1875 SNMPv3 did not include adequate security. Even if the 1876 network itself is secure (for example, by using IPsec), 1877 there is still no secure control over who on the secure 1878 network is allowed to access and GET/SET 1879 (read/change/create/delete) the objects in these MIB 1880 modules. 1882 It is recommended that implementers consider the security 1883 features as provided by the SNMPv3 framework (see 1884 [RFC3410], section 8), including full support for the 1885 SNMPv3 cryptographic mechanisms (for authentication and 1886 confidentiality). 1888 Further, deployment of SNMP versions prior to SNMPv3 is not 1889 recommended. Instead, it is recommended to deploy SNMPv3 1890 and to enable cryptographic security. It is then a 1891 customer/operator responsibility to ensure that the SNMP 1892 entity giving access to an instance of these MIB modules is 1893 properly configured to give access to the objects only to 1894 those principals (users) that have legitimate rights to GET 1895 or SET (change/create/delete) them. 1897 12. IANA Considerations 1898 12.1. IANA Registration of new Power State Sets 1900 This document specifies an initial set of Power State Sets. 1901 The list of these Power State Sets with their numeric 1902 identifiers is given is Section 6. IANA maintains the lists 1903 of Power State Sets. 1905 New assignments for Power State Set are administered by 1906 IANA through Expert Review [RFC5226], i.e., review by one 1907 of a group of experts designated by an IETF Area Director. 1908 The group of experts must check the requested state for 1909 completeness and accuracy of the description. A pure vendor 1910 specific implementation of Power State Set shall not be 1911 adopted; since it would lead to proliferation of Power 1912 State Sets. 1914 Power states in a Power State Set are limited to 255 1915 distinct values. New Power State Set must be assigned the 1916 next available numeric identifier that is a multiple of 1917 256. 1919 12.1.1. IANA Registration of the IEEE1621 Power State Set 1921 This document specifies a set of values for the IEEE1621 1922 Power State Set [IEEE1621]. The list of these values with 1923 their identifiers is given in Section 6.5.2. IANA created 1924 a new registry for IEEE1621 Power State Set identifiers and 1925 filled it with the initial list of identifiers. 1927 New assignments (or potentially deprecation) for the 1928 IEEE1621 Power State Set is administered by IANA through 1929 Expert Review [RFC5226], i.e., review by one of a group of 1930 experts designated by an IETF Area Director. The group of 1931 experts must check the requested state for completeness and 1932 accuracy of the description. 1934 12.1.2. IANA Registration of the DMTF Power State Set 1936 This document specifies a set of values for the DMTF Power 1937 State Set. The list of these values with their identifiers 1938 is given in Section 6.5.3. IANA has created a new registry 1939 for DMTF Power State Set identifiers and filled it with the 1940 initial list of identifiers. 1942 New assignments (or potentially deprecation) for the DMTF 1943 Power State Set is administered by IANA through Expert 1944 Review [RFC5226], i.e., review by one of a group of experts 1945 designated by an IETF Area Director. The group of experts 1946 must check the conformance with the DMTF standard [DMTF], 1947 on the top of checking for completeness and accuracy of the 1948 description. 1950 12.1.3. IANA Registration of the EMAN Power State Set 1952 This document specifies a set of values for the EMAN Power 1953 State Set. The list of these values with their identifiers 1954 is given in Section 6.5.4. IANA has created a new registry 1955 for EMAN Power State Set identifiers and filled it with the 1956 initial list of identifiers. 1958 New assignments (or potentially deprecation) for the EMAN 1959 Power State Set is administered by IANA through Expert 1960 Review [RFC5226], i.e., review by one of a group of experts 1961 designated by an IETF Area Director. The group of experts 1962 must check the requested state for completeness and 1963 accuracy of the description. 1965 12.2. Updating the Registration of Existing Power State Sets 1967 With the evolution of standards, over time, it may be 1968 important to deprecate some of the existing the Power State 1969 Sets, or to add or deprecate some Power States within a 1970 Power State Set. 1972 The registrant shall publish an Internet-draft or an 1973 individual submission with the clear specification on 1974 deprecation of Power State Sets or Power States registered 1975 with IANA. The deprecation or addition shall be 1976 administered by IANA through Expert Review [RFC5226], i.e., 1977 review by one of a group of experts designated by an IETF 1978 Area Director. The process should also allow for a 1979 mechanism for cases where others have significant 1980 objections to claims on deprecation of a registration. 1982 13. References 1984 Normative References 1986 [RFC2119] Bradner, S., "Key words for use in RFCs to 1987 Indicate Requirement Levels", BCP 14, RFC 2119, 1988 March 1997 1990 [RFC3410] Case, J., Mundy, R., Partain, D., and B. 1991 Stewart, "Introduction and Applicability 1992 Statements for Internet Standard Management 1993 Framework ", RFC 3410, December 2002 1995 [RFC3444] Pras, A., Schoenwaelder, J. "On the Differences 1996 between Information Models and Data Models", RFC 1997 3444, January 2003 1999 [RFC4122] Leach, P., Mealling, M., and R. Salz," A 2000 Universally Unique Identifier (UUID) URN 2001 Namespace", RFC 4122, July 2005 2003 [RFC5226] Narten, T., and H. Alvestrand, "Guidelines for 2004 Writing an IANA Considerations Section in RFCs", 2005 RFC 5226, May 2008 2007 [RFC6933] Bierman, A. and K. McCloghrie, "Entity MIB 2008 (Version4)", RFC 6933, May 2013 2010 [RFC6988] Quittek, J., Chandramouli, M., Winter, R., 2011 Dietz, T., and B. Claise, "Requirements for 2012 Energy Management", RFC 6988, Septembre 2013 2014 [ISO-IEC-19501-2005] ISO/IEC 19501:2005, Information 2015 technology, Open Distributed Processing -- 2016 Unified Modeling Language (UML), January 2005 2018 Informative References 2020 [RFC3986] T. Berners-Lee, Ed., " Uniform Resource 2021 Identifier (URI): Generic Syntax", RFC3 986, 2022 January 2005 2024 [RFC6982] Y. Sheffer, and Adrian Farrel, "Improving 2025 Awareness of Running Code: The Implementation 2026 Status Section", RFC 6982, July 2013 2028 [RFC7015] B. Trammell, A. Wagner, and B. Claise, "Flow 2029 Aggregation for the IP Flow Information Export 2030 (IPFIX) Protocol", RFC 7015, September 2013 2032 [ACPI] "Advanced Configuration and Power Interface 2033 Specification", http://www.acpi.info/spec30b.htm 2035 [IEEE1621] "Standard for User Interface Elements in Power 2036 Control of Electronic Devices Employed in 2037 Office/Consumer Environments", IEEE 1621, 2038 December 2004 2040 [ITU-T-M-3400] TMN Recommendation on Management Functions 2041 (M.3400), 1997 2043 [NMF] "Network Management Fundamentals", Alexander Clemm, 2044 ISBN: 1-58720-137-2, 2007 2046 [TMN] "TMN Management Functions : Performance Management", 2047 ITU-T M.3400 2049 [IEEE100] "The Authoritative Dictionary of IEEE Standards 2050 Terms" 2051 http://ieeexplore.ieee.org/xpl/mostRecentIssue.js 2052 p?punumber=4116785 2054 [ISO50001] "ISO 50001:2011 Energy management systems - 2055 Requirements with guidance for use", 2056 http://www.iso.org/ 2058 [IEC60050] International Electrotechnical Vocabulary 2059 http://www.electropedia.org/iev/iev.nsf/welcome?o 2060 penform 2062 [IEC61850] Power Utility Automation, 2063 http://www.iec.ch/smartgrid/standards/ 2065 [IEC61850-7-2] Abstract communication service interface 2066 (ACSI), http://www.iec.ch/smartgrid/standards/ 2068 [IEC61850-7-4] Compatible logical node classes and data 2069 classes, http://www.iec.ch/smartgrid/standards/ 2071 [DMTF] "Power State Management Profile DMTF DSP1027 2072 Version 2.0" December 2009 2073 http://www.dmtf.org/sites/default/files/standards 2074 /documents/DSP1027_2.0.0.pdf 2076 [IPENERGY] R. Aldrich, J. Parello "IP-Enabled Energy 2077 Management", 2010, Wiley Publishing 2079 [X.700] CCITT Recommendation X.700 (1992), Management 2080 framework for Open Systems Interconnection (OSI) 2081 for CCITT applications 2083 [ASHRAE-201] "ASHRAE Standard Project Committee 201 2084 (SPC 201)Facility Smart Grid Information 2085 Model", http://spc201.ashraepcs.org 2087 [CHEN] "The Entity-Relationship Model: Toward a Unified 2088 View of Data", Peter Pin-shan Chen, ACM 2089 Transactions on Database Systems, 1976 2091 [CISCO-EW] "Cisco EnergyWise Design Guide", John Parello, 2092 Roland Saville, Steve Kramling, Cisco Validated 2093 Designs, September 2010, 2094 http://www.cisco.com/en/US/docs/solutions/Enterpr 2095 ise/Borderless_Networks/Energy_Management/energyw 2096 isedg.html 2098 14. Acknowledgments 2100 The authors would like to thank Michael Brown for his 2101 editorial work improving the text dramatically. Thanks to 2102 Rolf Winter for his feedback and to Bill Mielke for 2103 feedback and very detailed review. Thanks to Bruce Nordman 2104 for brainstorming with numerous conference calls and 2105 discussions. Finally, the authors would like to thank the 2106 EMAN chairs: Nevil Brownlee, Bruce Nordman, and Tom Nadeau. 2108 This document was prepared using 2-Word-v2.0.template.dot. 2110 Appendix A. 2111 Information Model Listing 2113 EnergyObject (Class) 2115 r index Integer An RFC6933 2116 entPhysicalIndex 2118 w name String An RFC6933 2119 entPhysicalName 2121 r identifier uuid An [RFC6933] 2122 entPhysicalUUID 2124 rw alternatekey String A manufacturer defined 2125 string that can be 2126 used to identify the 2127 Energy Object 2129 rw domainName String The name of an Energy 2130 Management domain for 2131 the Energy Object 2133 rw role String An administratively 2134 assigned name to 2135 indicate the purpose 2136 an Energy Object 2137 serves in the network 2139 rw keywords String A list of keywords or 2140 [0..n] tags that can be used 2141 to group Energy 2142 Objects for reporting 2143 or searching 2145 rw importance Integer Specifies a ranking of 2146 how important the 2147 Energy Object is (on a 2148 scale of 1 to 100) 2149 compared with other 2150 Energy Objects 2152 rw relationships Relationship A list of 2153 [0..n] relationships between 2154 this Energy Object and 2155 other Energy Objects 2157 r nameplate Nameplate The nominal 2158 PowerMeasurement of 2159 the Energy Object as 2160 specified by the 2161 device manufacturer 2163 r power PowerMeasurement The present power 2164 measurement of the 2165 Energy Object 2167 r energy EnergyMeasurment The present energy 2168 measurement for the 2169 Energy Object 2171 r demand DemandMeasurement The present demand 2172 measurement for the 2173 Energy Object 2175 r powerControl PowerStateSet A list of Power States 2176 [0..n] Sets the Energy Object 2177 supports 2179 PowerInterface (Class) inherits from and specializes 2180 EnergyObject 2182 r eoIfType Enumeration Indicates if the Power 2183 Interface is an - 2184 inlet; outlet; both 2186 Device (Class) inherits from and specializes EnergyObject 2188 rw eocategory Enumeration Broadly indicates if 2189 the Device is a 2190 producer consumer meter 2191 distributor or store of 2192 energy 2194 r powerInterfaces PowerInterface A list of 2195 [0..n] PowerInterfaces 2196 contained in this 2197 Device 2199 r components Component A list of Components 2200 [0..n] contained in this 2201 Device 2203 Component (Class) inherits from and specializes 2204 EnergyObject 2206 rw eocategory Enumeration Broadly indicates if 2207 the Component is a 2208 producer consumer meter 2209 distributor or store of 2210 energy 2212 r powerInterfaces PowerInterface A list of 2213 [0..n] PowerInterfaces 2214 contained in this 2215 Component 2217 r components Component A list of Components 2218 [0..n] contained in this 2219 Component 2221 Nameplate (Class) 2223 r nominalPower PowerMeasuremen The nominal power of 2224 t the Energy Object as 2225 specified by the device 2226 manufacturer 2228 rw details URI an [RFC3986] URI that 2229 links to manufacturer 2230 information about the 2231 nominal power of a 2232 device 2234 Relationship (Class) 2236 rw relationshipType Enumeratio A description of the 2237 n relationhip indicating 2238 - meters; meteredby; 2239 powers; poweredby; 2240 aggregates; 2241 aggregatedby 2243 rw relationshipObject uuid An [RFC6933] 2244 entPhysicalUUID that 2245 indicates the other 2246 participating Energy 2247 Object in the 2248 relationship 2250 Measurement (Class) 2252 r multiplier Enumeration The magnitude of the 2253 Measurement in the range - 2254 24..24 2256 r caliber Enumeration Specifies how the Measurement 2257 was obtained - actual; 2258 estimated; static 2260 r accuracy Enumeration Specifies the accuracy of the 2261 measurement if applicable as 2262 0..10000 indicating hundreds 2263 of percent 2265 PowerMeasurement (Class) inherits from and specializes 2266 Measurement 2268 r value Long A measurement value of 2269 power 2271 r units "W" The units of measure for 2272 the power - "Watts" 2274 r powerAttribute PowerAttribute Measurement of the 2275 electrical current; 2276 voltage; phase and/or 2277 frequencies for the 2278 PowerMeasurement 2280 EnergyMeasurement (Class) inherits from and specializes 2281 Measurement 2283 r startTime Time Specifies the start time of the 2284 EnergyMeasurement interval 2286 r units "kWh" The units of measure for the 2287 energy - kilowatt hours 2289 r provided Long A measurement of energy 2290 provided 2292 r used Long A measurement of energy used / 2293 consumed 2295 r produced Long A measurement of energy 2296 produced 2298 r stored Long A measurement of energy stores 2300 TimedMeasurement (Class) inherits from and specializes 2301 Measurement 2303 r startTime timestamp A start time of a measurement 2305 r value Measurement A measurement value 2307 r maximum Measurement A maximum value measured since a 2308 previous timestamp 2310 TimeInterval (Class) 2312 r value Long a value of time 2314 r units Enumeration a magnitude of time express as 2315 seconds with an SI prefix 2316 (miliseconds etc) 2318 DemandMeasurement (Class) inherits from and specializes 2319 Measurement 2321 rw intervalLength TimeInterval The length of time 2322 over which to compute 2323 average energy 2325 rw intervals Long The number of 2326 intervals that can be 2327 measured 2329 rw intervalMode Enumeration The mode of interval 2330 measurement as - 2331 periodic; sliding; 2332 total 2334 rw intervalWindow TimeInterval The duration between 2335 the starting time of 2336 one sliding window and 2337 the next starting time 2339 rw sampleRate TimeInterval The sampling rate at 2340 which to poll power in 2341 order to compute 2342 demand 2344 rw status Enumeration a control to start or 2345 stop demand 2346 measurement as - 2347 active; inactive 2349 r measurements[0.TimedMeasurement a collection of 2350 .n] TimedMeasurements to 2351 compute demand 2353 PowerStateSet (Class) 2355 r powerSetIdentifier Integer an IANA assigned value 2356 indicating a Power 2357 State Set 2359 r name String A Power State Set name 2361 r powerStates [0..n] PowerState a set of Power States 2362 for the given 2363 identifier 2365 rw operState Integer The current 2366 operational Power 2367 State 2369 rw adminState Integer The desired Power 2370 State 2372 rw reason String Describes the reason 2373 for the adminState 2375 r configuredTime timestamp Indicates the time of 2376 the desired Power 2377 State 2379 PowerState (Class) 2381 r powerStateIdentifier Integer an IANA assigned value 2382 indicating a Power State 2384 r name String A name for the Power 2385 State 2387 r cardinality Integer A value indicating an 2388 ordering of the Power 2389 State 2391 rw maximumPower PowerMea indicates the maximum 2392 surement power for the Energy 2393 Object at this Power 2394 State 2396 r totalTimeInState Time Indicates the total time 2397 an Energy Object has 2398 been in this Power State 2399 since last reset 2401 r entryCount Long Indicates the number of 2402 time the Energy Object 2403 has entered changed to 2404 this state 2406 PowerAttribute (Class) 2408 r acQuality ACQuality Describes AC Power Attributes for 2409 a Measurement 2411 ACQuality (Class) 2413 r acConfiguration Enumera Describes the physical 2414 tion configuration of 2415 alternating current as 2416 single phase (SNGL) three 2417 phase delta (DEL) or three 2418 phase Y (WYE) 2420 r avgVoltage Long The average of the voltage 2421 measured over an integral 2422 number of AC cycles 2423 [IEC61850-7-4] 'Vol' 2425 r avgCurrent Long The current per phase 2426 [IEC61850-7-4] 'Amp' 2428 r frequency Long Basic frequency of the AC 2429 circuit [IEC61850-7-4] 'Hz' 2431 r unitMultiplier Integer Magnitude of watts for the 2432 usage value in this 2433 instance 2435 r accuracy Integer Percentage value in 100ths 2436 of a percent representing 2437 the presumed accuracy of 2438 active; reactive; and 2439 apparent power in this 2440 instance 2442 r totalActivePower Long A measured value of the 2443 actual power delivered to 2444 or consumed by the load 2445 [IEC61850-7-4] 'TotW' 2447 r totalReactivePower Long A measured value of the 2448 reactive portion of the 2449 apparent power [IEC61850-7- 2450 4] 'TotVAr' 2452 r totalApparentPower Long A measured value of the 2453 voltage and current which 2454 determines the apparent 2455 power as the vector sum of 2456 real and reactive power 2457 [IEC61850-7-4] 'TotVA' 2459 r totalPowerFactor Long A measured value of the 2460 ratio of the real power 2461 flowing to the load versus 2462 the apparent power 2463 [IEC61850-7-4] 'TotPF' 2465 r phases [0..2] ACPhase A description of the three 2466 phase power 2468 ACPhase (Class) 2470 r phaseIndex Long A phase angle typically 2471 corresponding to - 0; 120; 240 2473 r avgCurrent Long A measured value of the current per 2474 phase [IEC61850-7-4] 'A' 2476 r activePower Long A measured value of the actual 2477 power delivered to or consumed by 2478 the load [IEC61850-7-4] 'W' 2480 r reactivePower Long A measured value of the reactive 2481 portion of the apparent power 2482 [IEC61850-7-4] 'VAr' 2484 r apparentPower Long A measured value of the active plus 2485 reactive power [IEC61850-7-4] 'VA' 2487 r powerFactor Long A measure ratio of the real power 2488 flowing to the load versus the 2489 apparent power for this phase 2491 [IEC61850-7-4] 'PF' 2493 DelPhase (Class) inherits from and specializes ACPhase 2495 r phaseToNextPhas Long A measured value of phase to 2496 eVoltage next phase voltages where the 2497 next phase is [IEC61850-7-4] 2498 'PPV' 2500 r thdVoltage Long A calculated value for the 2501 voltage total harmonic disortion 2502 for phase to next phase. Method 2503 of calculation is not specified 2504 [IEC61850-7-4] 'ThdPPV' 2506 r thdCurrent Long A calculated value for the 2507 voltage total harmonic disortion 2508 (THD) for phase to phase. Method 2509 of calculation is not specified 2510 [IEC61850-7-4] 'ThdPPV' 2512 WYEPhase (Class) inherits from and specializes ACPhase 2514 r phaseToNeutral Long A measured value of phase to 2515 Voltage neutral voltage [IEC61850-7-4] 2516 'PhV' 2518 r thdCurrent Long A measured value of phase currents 2519 [IEC61850-7-4] 'A' 2521 r thdVoltage Long A calculated value of the voltage 2522 total harmonic distortion (THD) 2523 for phase to neutral [IEC61850-7- 2524 4] 'ThdPhV' 2526 Authors' Addresses 2528 John Parello 2529 Cisco Systems, Inc. 2530 3550 Cisco Way 2531 San Jose, California 95134 2532 US 2534 Phone: +1 408 525 2339 2535 Email: jparello@cisco.com 2537 Benoit Claise 2538 Cisco Systems, Inc. 2539 De Kleetlaan 6a b1 2540 Diegem 1813 2541 BE 2543 Phone: +32 2 704 5622 2544 Email: bclaise@cisco.com 2546 Brad Schoening 2547 44 Rivers Edge Drive 2548 Little Silver, NJ 07739 2549 US 2551 Phone: 2552 Email: brad.schoening@verizon.net 2554 Juergen Quittek 2555 NEC Europe Ltd. 2556 Network Laboratories 2557 Kurfuersten-Anlage 36 2558 69115 Heidelberg 2559 Germany 2561 Phone: +49 6221 90511 15 2562 EMail: quittek@netlab.nec.de