p2030.5™ d1
TRANSCRIPT
P2030.5/D1, June 2013 Draft Standard for Smart Energy Profile 2.0 Application Protocol
P2030.5™/D1 1
Draft Standard for Smart Energy Profile 2
2.0 Application Protocol 3
Sponsor 4 5 Power Line Communications (COM/PLC) 6 of the 7 IEEE IEEE Communications Society 8 9 10 Approved <Date Approved> 11 12 IEEE-SA Standards Board 13 14 Copyright © 2013 by the Institute of Electrical and Electronics Engineers, Inc. 15 Three Park Avenue 16 New York, New York 10016-5997, USA 17 All rights reserved. 18
This document is an unapproved draft of a proposed IEEE Standard. As such, this document is subject to 19 change. USE AT YOUR OWN RISK! Because this is an unapproved draft, this document must not be 20 utilized for any conformance/compliance purposes. Permission is hereby granted for IEEE Standards 21 Committee participants to reproduce this document for purposes of international standardization 22 consideration. Prior to adoption of this document, in whole or in part, by another standards development 23 organization, permission must first be obtained from the IEEE Standards Activities Department 24 ([email protected]). Other entities seeking permission to reproduce this document, in whole or in part, must 25 also obtain permission from the IEEE Standards Activities Department. 26 IEEE Standards Activities Department 27 445 Hoes Lane 28 Piscataway, NJ 08854, USA 29 30
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
P2030.5/D1, June 2013 Draft Standard for Smart Energy Profile 2.0 Application Protocol
Abstract: This standard defines the 'APPLICATION' layer with TCP/IP providing functions in the 1 'TRANSPORT' and 'INTERNET' layers. Depending on the physical layer in use (e.g., IEEE 2 802.15.4™, IEEE 802.11™, IEEE 1901™), a variety of lower layer protocols may be involved in 3 providing a complete solution. Generally, lower layer protocols are not discussed in this standard 4 except where there is a direct interaction with the application protocol. This standard defines the 5 mechanisms for exchanging application messages, the exact messages exchanged including 6 error messages, and the security features used to protect the application messages. With respect 7 to the OSI network model, this standard is built using the four-layer Internet stack model. The 8 defined application protocol is an IEC 61968 common information model [61968] profile, mapping 9 directly where possible, and using subsets and extensions where needed, and follows an IETF 10 RESTful architecture [REST] 11 Keywords: adoption, application, application protocol, IEEE 2030, smart energy, smart energy 12 profile 13 14
•15
The Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue, New York, NY 10016-5997, USA Copyright © 2013 by The Institute of Electrical and Electronics Engineers, Inc. All rights reserved. Published <Date Published>. Printed in the United States of America. IEEE is a registered trademark in the U.S. Patent & Trademark Office, owned by The Institute of Electrical and Electronics Engineers, Incorporated. PDF: ISBN 978-0-XXXX-XXXX-X STDXXXXX Print: ISBN 978-0-XXXX-XXXX-X STDPDXXXXX IEEE prohibits discrimination, harassment, and bullying. For more information, visit http://www.ieee.org/web/aboutus/whatis/policies/p9-26.html. No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher.
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
P2030.5/D1, June 2013 Draft Standard for Smart Energy Profile 2.0 Application Protocol
Notice and Disclaimer of Liability Concerning the Use of IEEE Documents: IEEE Standards documents are developed 1 within the IEEE Societies and the Standards Coordinating Committees of the IEEE Standards Association (IEEE-SA) 2 Standards Board. IEEE develops its standards through a consensus development process, approved by the American National 3 Standards Institute, which brings together volunteers representing varied viewpoints and interests to achieve the final product. 4 Volunteers are not necessarily members of the Institute and serve without compensation. While IEEE administers the process 5 and establishes rules to promote fairness in the consensus development process, IEEE does not independently evaluate, test, or 6 verify the accuracy of any of the information or the soundness of any judgments contained in its standards. 7
Use of an IEEE Standard is wholly voluntary. IEEE disclaims liability for any personal injury, property or other damage, of 8 any nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly resulting from the 9 publication, use of, or reliance upon any IEEE Standard document. 10
IEEE does not warrant or represent the accuracy or content of the material contained in its standards, and expressly disclaims 11 any express or implied warranty, including any implied warranty of merchantability or fitness for a specific purpose, or that 12 the use of the material contained in its standards is free from patent infringement. IEEE Standards documents are supplied "AS 13 IS." 14
The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase, market, or 15 provide other goods and services related to the scope of the IEEE standard. Furthermore, the viewpoint expressed at the time a 16 standard is approved and issued is subject to change brought about through developments in the state of the art and comments 17 received from users of the standard. Every IEEE standard is subjected to review at least every ten years. When a document is 18 more than ten years old and has not undergone a revision process, it is reasonable to conclude that its contents, although still of 19 some value, do not wholly reflect the present state of the art. Users are cautioned to check to determine that they have the 20 latest edition of any IEEE standard. 21
In publishing and making its standards available, IEEE is not suggesting or rendering professional or other services for, or on 22 behalf of, any person or entity. Nor is IEEE undertaking to perform any duty owed by any other person or entity to another. 23 Any person utilizing any IEEE Standards document, should rely upon his or her own independent judgment in the exercise of 24 reasonable care in any given circumstances or, as appropriate, seek the advice of a competent professional in determining the 25 appropriateness of a given IEEE standard. 26
Translations: The IEEE consensus development process involves the review of documents in English only. In the event that 27 an IEEE standard is translated, only the English version published by IEEE should be considered the approved IEEE standard. 28
Official Statements: A statement, written or oral, that is not processed in accordance with the IEEE-SA Standards Board 29 Operations Manual shall not be considered the official position of IEEE or any of its committees and shall not be considered to 30 be, nor be relied upon as, a formal position of IEEE. At lectures, symposia, seminars, or educational courses, an individual 31 presenting information on IEEE standards shall make it clear that his or her views should be considered the personal views of 32 that individual rather than the formal position of IEEE. 33
Comments on Standards: Comments for revision of IEEE Standards documents are welcome from any interested party, 34 regardless of membership affiliation with IEEE. However, IEEE does not provide consulting information or advice pertaining 35 to IEEE Standards documents. Suggestions for changes in documents should be in the form of a proposed change of text, 36 together with appropriate supporting comments. Since IEEE standards represent a consensus of concerned interests, it is 37 important to ensure that any responses to comments and questions also receive the concurrence of a balance of interests. For 38 this reason, IEEE and the members of its societies and Standards Coordinating Committees are not able to provide an instant 39 response to comments or questions except in those cases where the matter has previously been addressed. Any person who 40 would like to participate in evaluating comments or revisions to an IEEE standard is welcome to join the relevant IEEE 41 working group at http://standards.ieee.org/develop/wg/. 42
Comments on standards should be submitted to the following address: 43
Secretary, IEEE-SA Standards Board 44 445 Hoes Lane 45 Piscataway, NJ 08854 46 USA 47
Photocopies: Authorization to photocopy portions of any individual standard for internal or personal use is granted by The 48 Institute of Electrical and Electronics Engineers, Inc., provided that the appropriate fee is paid to Copyright Clearance Center. 49 To arrange for payment of licensing fee, please contact Copyright Clearance Center, Customer Service, 222 Rosewood Drive, 50 Danvers, MA 01923 USA; +1 978 750 8400. Permission to photocopy portions of any individual standard for educational 51 classroom use can also be obtained through the Copyright Clearance Center. 52
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
P2030.5/D1, June 2013 Draft Standard for Smart Energy Profile 2.0 Application Protocol
Copyright © 2013 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
iv
Notice to users 1
Laws and regulations 2
Users of IEEE Standards documents should consult all applicable laws and regulations. Compliance with 3 the provisions of any IEEE Standards document does not imply compliance to any applicable regulatory 4 requirements. Implementers of the standard are responsible for observing or referring to the applicable 5 regulatory requirements. IEEE does not, by the publication of its standards, intend to urge action that is not 6 in compliance with applicable laws, and these documents may not be construed as doing so. 7
Copyrights 8
This document is copyrighted by the IEEE. It is made available for a wide variety of both public and 9 private uses. These include both use, by reference, in laws and regulations, and use in private self-10 regulation, standardization, and the promotion of engineering practices and methods. By making this 11 document available for use and adoption by public authorities and private users, the IEEE does not waive 12 any rights in copyright to this document. 13
Updating of IEEE documents 14
Users of IEEE Standards documents should be aware that these documents may be superseded at any time 15 by the issuance of new editions or may be amended from time to time through the issuance of amendments, 16 corrigenda, or errata. An official IEEE document at any point in time consists of the current edition of the 17 document together with any amendments, corrigenda, or errata then in effect. In order to determine whether 18 a given document is the current edition and whether it has been amended through the issuance of 19 amendments, corrigenda, or errata, visit the IEEE-SA Website at http://standards.ieee.org/index.html or 20 contact the IEEE at the address listed previously. For more information about the IEEE Standards 21 Association or the IEEE standards development process, visit IEEE-SA Website at 22 http://standards.ieee.org/index.html. 23
Errata 24
Errata, if any, for this and all other standards can be accessed at the following URL: 25 http://standards.ieee.org/findstds/errata/index.html. Users are encouraged to check this URL for errata 26 periodically. 27
Patents 28
Attention is called to the possibility that implementation of this standard may require use of subject matter 29 covered by patent rights. By publication of this standard, no position is taken by the IEEE with respect to 30 the existence or validity of any patent rights in connection therewith. If a patent holder or patent applicant 31 has filed a statement of assurance via an Accepted Letter of Assurance, then the statement is listed on the 32 IEEE-SA Website at http://standards.ieee.org/about/sasb/patcom/patents.html. Letters of Assurance may 33 indicate whether the Submitter is willing or unwilling to grant licenses under patent rights without 34 compensation or under reasonable rates, with reasonable terms and conditions that are demonstrably free of 35 any unfair discrimination to applicants desiring to obtain such licenses. 36
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
P2030.5/D1, June 2013 Draft Standard for Smart Energy Profile 2.0 Application Protocol
Copyright © 2013 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
v
Essential Patent Claims may exist for which a Letter of Assurance has not been received. The IEEE is not 1 responsible for identifying Essential Patent Claims for which a license may be required, for conducting 2 inquiries into the legal validity or scope of Patents Claims, or determining whether any licensing terms or 3 conditions provided in connection with submission of a Letter of Assurance, if any, or in any licensing 4 agreements are reasonable or non-discriminatory. Users of this standard are expressly advised that 5 determination of the validity of any patent rights, and the risk of infringement of such rights, is entirely 6 their own responsibility. Further information may be obtained from the IEEE Standards Association. 7
8
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
P2030.5/D1, June 2013 Draft Standard for Smart Energy Profile 2.0 Application Protocol
Copyright © 2013 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
vi
Participants 1
At the time this draft standard was completed, the Smart Energy Profile 2.0 (COM/PLC/SEP2) Working 2 Group had the following membership: 3
Robert Heile, Chair 4 <Vice-chair Name>, Vice Chair 5
6 Participant1 7 Participant2 8 Participant3 9
Participant4 10 Participant5 11 Participant6 12
Participant7 13 Participant8 14 Participant9 15
16
The following members of the entity balloting committee voted on this standard. Balloters may have voted 17 for approval, disapproval, or abstention. 18
[To be supplied by IEEE] 19
Balloter1 20 Balloter2 21 Balloter3 22
Balloter4 23 Balloter5 24 Balloter6 25
Balloter7 26 Balloter8 27 Balloter9 28
29
When the IEEE-SA Standards Board approved this standard on <Date Approved>, it had the following 30 membership: 31
[To be supplied by IEEE] 32
<Name>, Chair 33 <Name>, Vice Chair 34 <Name>, Past Chair 35 <Name>, Secretary 36
SBMember1 37 SBMember2 38 SBMember3 39
SBMember4 40 SBMember5 41 SBMember6 42
SBMember7 43 SBMember8 44 SBMember9 45
*Member Emeritus 46 47
Also included are the following nonvoting IEEE-SA Standards Board liaisons: 48
<Name>, DOE Representative 49 <Name>, NIST Representative 50
51 <Name> 52
IEEE Standards Program Manager, Document Development 53 54
<Name> 55 IEEE Standards Program Manager, Technical Program Development 56
57
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
P2030.5/D1, June 2013 Draft Standard for Smart Energy Profile 2.0 Application Protocol
Copyright © 2013 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
vii
Introduction 1
This introduction is not part of P2030.5/D1, Draft Standard for Smart Energy Profile 2.0 Application Protocol. 2
<Select this text and type or paste introduction text> 3
4
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
P2030.5/D1, June 2013 Draft Standard for Smart Energy Profile 2.0 Application Protocol
Copyright © 2013 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
viii
Contents 1
<After draft body is complete, select this text and click Insert Special->Add (Table of) Contents> 2
3
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
P2030.5/D1, June 2013 Draft Standard for Smart Energy Profile 2.0 Application Protocol
Copyright © 2013 IEEE. All rights reserved.
This is an unapproved IEEE Standards Draft, subject to change.
1
Draft Standard for Smart Energy Profile 1
2.0 Application Protocol 2
IMPORTANT NOTICE: IEEE Standards documents are not intended to ensure safety, health, or 3 environmental protection, or ensure against interference with or from other devices or networks. 4 Implementers of IEEE Standards documents are responsible for determining and complying with all 5 appropriate safety, security, environmental, health, and interference protection practices and all 6 applicable laws and regulations. 7
This IEEE document is made available for use subject to important notices and legal disclaimers. 8 These notices and disclaimers appear in all publications containing this document and may 9 be found under the heading “Important Notice” or “Important Notices and Disclaimers 10 Concerning IEEE Documents.” They can also be obtained on request from IEEE or viewed at 11 http://standards.ieee.org/IPR/disclaimers.html. 12
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 1 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
1
2
3
4
5
6
7
8
Smart Energy Profile 2 9
Application Protocol Standard 10
11
12
ZigBee Public Document 13-0200-00
April 2013
Sponsored by: ZigBee Alliance
Accepted by This document has been accepted for release by the ZigBee Alliance Board of Directors.
Abstract This document describes Smart Energy Profile 2, an IP-based standard for energy management and communications.
Keywords Smart Energy Profile 2, SEP 2, Demand Response and Load Control, Pricing Communication, Energy Usage Information, Metering, Prepayment, Plugin Electric Vehicles, Distributed Energy Resources, RESTful
13
14
15
April 2013 16
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 2 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
17
18 19
20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36
This page is intentionally blank. 37
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 3 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Notice of use and disclosure 38
Copyright 2011-2013 © ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights Reserved. This 39 information within this document is the property of the ZigBee Alliance and the HomePlug Powerline Alliance and 40 its use and disclosure are restricted. 41
Elements of ZigBee Alliance and HomePlug Powerline Alliance specifications may be subject to third party 42 intellectual property rights, including without limitation, patent, copyright or trademark rights (such a third party 43 MAY or MAY NOT be a member of ZigBee and / or HomePlug). ZigBee and HomePlug are not responsible and 44 SHALL NOT be held responsible in any manner for identifying or failing to identify any or all such third party 45 intellectual property rights. 46
This document and the information contained herein are provided on an "AS IS" basis and ZigBee and HomePlug 47 DISCLAIM ALL WARRANTIES EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO (A) ANY 48 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OF 49 THIRD PARTIES (INCLUDING WITHOUT LIMITATION ANY INTELLECTUAL PROPERTY RIGHTS 50 INCLUDING PATENT, COPYRIGHT OR TRADEMARK RIGHTS) OR (B) ANY IMPLIED WARRANTIES OF 51 MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE OR NON-INFRINGEMENT. IN 52 NO EVENT WILL ZIGBEE OR HOMEPLUG BE LIABLE FOR ANY LOSS OF PROFITS, LOSS OF 53 BUSINESS, LOSS OF USE OF DATA, INTERRUPTION OF BUSINESS, OR FOR ANY OTHER DIRECT, 54 INDIRECT, SPECIAL OR EXEMPLARY, INCIDENTIAL, PUNITIVE OR CONSEQUENTIAL DAMAGES OF 55 ANY KIND, IN CONTRACT OR IN TORT, IN CONNECTION WITH THIS DOCUMENT OR THE 56 INFORMATION CONTAINED HEREIN, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH LOSS OR 57 DAMAGE. All Company, brand and product names may be trademarks that are the sole property of their respective 58 owners. 59
The above notice and this paragraph MUST be included on all copies of this document that are made. 60
ZigBee Alliance, Inc. HomePlug Powerline Alliance, Inc. 61 2400 Camino Ramon, Suite 375 5200 SW Macadam Ave., Suite 470 62 San Ramon, CA 94583 Portland, OR 97239 63
64
65
66
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 4 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
67
68
69
70
71
72
73
74
75
76
77
78
79
80
This page is intentionally blank. 81
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 5 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Foreword 82
The empowerment of consumers to manage their usage and generation of energy is a critical feature of 83 the Smart Grid and is a basis of innovation for new products and services in energy management. To 84 enable this capability, information flow between devices such as meters, smart appliances, plug-in electric 85 vehicles, energy management systems, and distributed energy resources (including renewable energy and 86 storage elements) must occur in an open, standardized, secure, and interoperable fashion. The following 87 specification is intended to fulfill those needs. 88
The development of this document has been driven by, and seeks to address the requirements of, many 89 activities across the globe. Of note are the efforts within the United States by the National Institute of 90 Standards and Technology (NIST) and the Smart Grid Interoperability Panel (SGIP) (in particular, 91 Priority Action Plans 3, 9, 10, 11, and 18, with influence from many of the others) in fulfillment of the 92 EISA 2007 legislation, the European Mandate on Smart Metering (M / 441) (in particular, efforts within 93 CEN / CENELEC and ETSI, and the Smart Meter Working Group), as well as similar efforts in Australia, 94 the United Kingdom, Japan, and China, and electric vehicle standardization efforts (in particular, ISO / 95 IEC JWG automotive EV standards and SAE EV standards), to name only a few. 96
Readers should note that this document was readied for balloting under the policies set forth in the 97 ZigBee Alliance. Previous revisions of this document have gone through review both within the ZigBee 98 Alliance as well as made available for public comment. All previously received comments have been 99 considered for this specification. This specification is intended to meet the requirements set forth in the 100 previously published Technical Requirements Document (TRD). 101
This document is also intended to enable communications that are link-layer agnostic and run over the 102 Internet Protocol. Careful consideration was given to premises networks with various architectures, 103 numbers of devices, and constraints while maintaining flexibility, extensibility, and security.104
105
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 6 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Table of Contents 106 Smart Energy Profile 2 Application Protocol Standard .......................................................................................... 1 107 1 Introduction ................................................................................................................................................ 17 108
1.1 Purpose....................................................................................................................................................... 17 109 1.2 Scope .......................................................................................................................................................... 17 110 1.3 Context Overview ....................................................................................................................................... 17 111 1.4 Document Organization ............................................................................................................................. 17 112 1.5 Requirement Language .............................................................................................................................. 18 113 1.6 Typography Conventions Used ................................................................................................................... 18 114 1.7 Design Principles ........................................................................................................................................ 18 115
2 Acknowledgements ..................................................................................................................................... 19 116 3 Document Revision History ......................................................................................................................... 20 117 4 References .................................................................................................................................................. 21 118
4.1 Smart Energy 2.0 Documents ..................................................................................................................... 21 119 4.2 IEC Documents ........................................................................................................................................... 21 120 4.3 IETF Documents .......................................................................................................................................... 21 121 4.4 Other References ........................................................................................................................................ 22 122
5 Definitions, Acronyms and Abbreviations ................................................................................................... 24 123 5.1 Acronyms and Abbreviations...................................................................................................................... 24 124 5.2 Definitions .................................................................................................................................................. 25 125
6 Design Pattern ............................................................................................................................................. 28 126 6.1 Protocol Flexibility ...................................................................................................................................... 28 127 6.2 General Rules / Best Practices .................................................................................................................... 28 128 6.3 WADL.......................................................................................................................................................... 29 129 6.4 Schema ....................................................................................................................................................... 29 130 6.5 Uniform Resource Identifiers ...................................................................................................................... 29 131 6.6 List Resources ............................................................................................................................................. 30 132
6.6.1 Query String Parameters ....................................................................................................................... 30 133 6.7 Resource Design Rules ................................................................................................................................ 33 134
7 Application Support .................................................................................................................................... 35 135 7.1 Overview .................................................................................................................................................... 35 136 7.2 Use of TCP .................................................................................................................................................. 35 137 7.3 URI Encoding .............................................................................................................................................. 35 138 7.4 HTTP Headers ............................................................................................................................................. 35 139
7.4.1 HTTP Header Field Recommended Usage ............................................................................................. 36 140 7.5 HTTP Response Codes ................................................................................................................................. 38 141
7.5.1 Common Responses .............................................................................................................................. 38 142 7.5.2 Minimal Understanding ......................................................................................................................... 40 143
7.6 Application Payload Syntax ........................................................................................................................ 41 144 7.6.1 XML Encoding ........................................................................................................................................ 41 145 7.6.2 EXI Encoding........................................................................................................................................... 41 146
7.7 Content Negotiation ................................................................................................................................... 41 147 7.7.1 Schema Version Negotiation ................................................................................................................. 41 148
8 Security ....................................................................................................................................................... 43 149 8.1 Introduction ................................................................................................................................................ 43 150 8.2 Security Attributes ...................................................................................................................................... 43 151
8.2.1 Local Registration Attributes ................................................................................................................. 43 152 8.2.2 Access Control List (ACL) Attributes ....................................................................................................... 44 153
8.3 Device Credentials ...................................................................................................................................... 48 154
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 7 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
8.3.1 Certificate Fingerprint ............................................................................................................................ 49 155 8.3.2 Short-form Device Identifier (SFDI)........................................................................................................ 49 156 8.3.3 Long-form Device Identifier (LFDI) ......................................................................................................... 49 157 8.3.4 6-digit PIN code ...................................................................................................................................... 49 158 8.3.5 Registration Code .................................................................................................................................. 50 159
8.4 Resource Access Authentication and Authorization context ...................................................................... 50 160 8.5 Resource Access Authentication ................................................................................................................. 51 161 8.6 Resource Access Authorization ................................................................................................................... 52 162 8.7 Cipher Suites ............................................................................................................................................... 52 163 8.8 Default Security Policy ................................................................................................................................ 52 164 8.9 Registration ................................................................................................................................................ 54 165
8.9.1 EndDeviceList ......................................................................................................................................... 55 166 8.10 Security LogEvents ...................................................................................................................................... 56 167 8.11 Certificate Management ............................................................................................................................ 56 168
8.11.1 Introduction ....................................................................................................................................... 56 169 8.11.2 Certificate Usage – Authentication vs. Authorization ....................................................................... 58 170 8.11.3 Manufacturing PKI ............................................................................................................................. 59 171 8.11.4 General Certificate Format ................................................................................................................ 60 172 8.11.5 General Restrictions and Conditions ................................................................................................. 61 173 8.11.6 Extensions.......................................................................................................................................... 61 174 8.11.7 Additional ASN1 Definitions .............................................................................................................. 62 175 8.11.8 Certificate Profiles ............................................................................................................................. 63 176 8.11.9 Device Requirements ........................................................................................................................ 67 177 8.11.10 Certificate Verification....................................................................................................................... 68 178 8.11.11 Certificate Related Labeling Requirements ....................................................................................... 68 179
9 Discovery..................................................................................................................................................... 69 180 9.1 Service Instance .......................................................................................................................................... 69 181 9.2 Service Name .............................................................................................................................................. 70 182 9.3 TXT Record.................................................................................................................................................. 70 183 9.4 Subtype Queries ......................................................................................................................................... 71 184 9.5 Discovery Procedure ................................................................................................................................... 73 185
10 Support Resources ...................................................................................................................................... 74 186 10.1 Resource Section Outlines .......................................................................................................................... 74 187
10.1.1 Overview ........................................................................................................................................... 74 188 10.1.2 List Ordering ...................................................................................................................................... 74 189 10.1.3 Application Guidelines / Behavior ..................................................................................................... 74 190 10.1.4 LogEvents .......................................................................................................................................... 75 191
10.2 Device Capabilities Function Set ................................................................................................................. 75 192 10.2.1 Overview ........................................................................................................................................... 75 193 10.2.2 List Ordering ...................................................................................................................................... 75 194 10.2.3 Application Guidelines / Behavior ..................................................................................................... 75 195 10.2.4 LogEvents .......................................................................................................................................... 75 196
10.3 Self Device Resource ................................................................................................................................... 75 197 10.3.1 Overview ........................................................................................................................................... 75 198 10.3.2 List Ordering ...................................................................................................................................... 75 199 10.3.3 Application Guidelines / Behavior ..................................................................................................... 75 200 10.3.4 LogEvents .......................................................................................................................................... 76 201
10.4 End Device Resource................................................................................................................................... 76 202 10.4.1 Overview ........................................................................................................................................... 76 203
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 8 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
10.4.2 List Ordering ...................................................................................................................................... 76 204 10.4.3 Application Guidelines / Behavior ..................................................................................................... 76 205 10.4.4 LogEvents .......................................................................................................................................... 77 206
10.5 Function Set Assignments .......................................................................................................................... 77 207 10.5.1 Overview ........................................................................................................................................... 77 208 10.5.2 List Ordering ...................................................................................................................................... 78 209 10.5.3 Application Guidelines / Behavior ..................................................................................................... 78 210 10.5.4 LogEvents .......................................................................................................................................... 78 211
10.6 Subscription / Notification Mechanism ...................................................................................................... 78 212 10.6.1 Overview ........................................................................................................................................... 78 213 10.6.2 List Ordering ...................................................................................................................................... 79 214 10.6.3 Application Guidelines / Behavior ..................................................................................................... 79 215 10.6.4 LogEvents .......................................................................................................................................... 81 216
10.7 Response .................................................................................................................................................... 81 217 10.7.1 Overview ........................................................................................................................................... 81 218 10.7.2 List Ordering ...................................................................................................................................... 81 219 10.7.3 Application Guidelines / Behavior ..................................................................................................... 81 220 10.7.4 LogEvents .......................................................................................................................................... 85 221
11 Common Resources ..................................................................................................................................... 86 222 11.1 Time Function Set ....................................................................................................................................... 86 223
11.1.1 Overview ........................................................................................................................................... 86 224 11.1.2 List Ordering ...................................................................................................................................... 86 225 11.1.3 Application Guidelines / Behavior ..................................................................................................... 86 226 11.1.4 LogEvents .......................................................................................................................................... 87 227
11.2 DeviceInformation Function Set ................................................................................................................. 87 228 11.2.1 Overview ........................................................................................................................................... 87 229 11.2.2 List Ordering ...................................................................................................................................... 87 230 11.2.3 Application Guidelines / Behavior ..................................................................................................... 87 231 11.2.4 LogEvents .......................................................................................................................................... 87 232
11.3 Power Status .............................................................................................................................................. 88 233 11.3.1 Overview ........................................................................................................................................... 88 234 11.3.2 List Ordering ...................................................................................................................................... 88 235 11.3.3 Application Guidelines / Behavior ..................................................................................................... 88 236 11.3.4 LogEvents .......................................................................................................................................... 88 237
11.4 Network Status ........................................................................................................................................... 88 238 11.4.1 Overview ........................................................................................................................................... 88 239 11.4.2 List Ordering ...................................................................................................................................... 88 240 11.4.3 Application Guidelines / Behavior ..................................................................................................... 89 241 11.4.4 LogEvents .......................................................................................................................................... 89 242
11.5 LogEvent List .............................................................................................................................................. 89 243 11.5.1 Overview ........................................................................................................................................... 89 244 11.5.2 List Ordering ...................................................................................................................................... 89 245 11.5.3 Application Guidelines / Behavior ..................................................................................................... 90 246
11.6 Configuration Resource .............................................................................................................................. 90 247 11.6.1 Overview ........................................................................................................................................... 90 248 11.6.2 List Ordering ...................................................................................................................................... 90 249 11.6.3 Application Guidelines / Behavior ..................................................................................................... 90 250 11.6.4 LogEvents .......................................................................................................................................... 91 251
11.7 File Download Function Set ........................................................................................................................ 91 252
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 9 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
11.7.1 File List Resource ............................................................................................................................... 91 253 11.7.2 File Status Resource .......................................................................................................................... 94 254
12 Smart Energy Resources .............................................................................................................................. 96 255 12.1 Common Functionality ............................................................................................................................... 96 256
12.1.1 Overview ........................................................................................................................................... 96 257 12.1.2 Active List Elements ........................................................................................................................... 96 258 12.1.3 Event Rules and Guidelines ............................................................................................................... 96 259 12.1.4 Randomization .................................................................................................................................. 99 260 12.1.5 Multi-Server ..................................................................................................................................... 101 261
12.2 Demand Response and Load Control ....................................................................................................... 102 262 12.2.1 Overview ......................................................................................................................................... 102 263 12.2.2 List Ordering .................................................................................................................................... 102 264 12.2.3 Application Guidelines / Behavior ................................................................................................... 103 265 12.2.4 LogEvents ........................................................................................................................................ 105 266
12.3 Metering Function Set .............................................................................................................................. 105 267 12.3.1 Overview ......................................................................................................................................... 105 268 12.3.2 List Ordering .................................................................................................................................... 105 269 12.3.3 Application Guidelines / Behavior ................................................................................................... 105 270 12.3.4 LogEvents ........................................................................................................................................ 109 271
12.4 Pricing Function Set .................................................................................................................................. 111 272 12.4.1 Overview ......................................................................................................................................... 111 273 12.4.2 List Ordering .................................................................................................................................... 111 274 12.4.3 Application Guidelines / Behavior ................................................................................................... 111 275 12.4.4 LogEvents ........................................................................................................................................ 115 276
12.5 Messaging Function Set ........................................................................................................................... 115 277 12.5.1 Overview ......................................................................................................................................... 115 278 12.5.2 List Ordering .................................................................................................................................... 115 279 12.5.3 Application Guidelines / Behavior ................................................................................................... 116 280 12.5.4 LogEvents ........................................................................................................................................ 116 281
12.6 Billing Function Set ................................................................................................................................... 116 282 12.6.1 Overview ......................................................................................................................................... 116 283 12.6.2 List Ordering .................................................................................................................................... 117 284 12.6.3 Application Guidelines / Behavior ................................................................................................... 117 285 12.6.4 LogEvents ........................................................................................................................................ 119 286
12.7 Prepayment Function Set ......................................................................................................................... 119 287 12.7.1 Overview ......................................................................................................................................... 119 288 12.7.2 List Ordering .................................................................................................................................... 119 289 12.7.3 Application Guidelines / Behavior ................................................................................................... 119 290 12.7.4 LogEvents ........................................................................................................................................ 121 291
12.8 Energy Flow Reservation Function Set ..................................................................................................... 121 292 12.8.1 Overview ......................................................................................................................................... 121 293 12.8.2 List Ordering .................................................................................................................................... 121 294 12.8.3 Application Guidelines / Behavior ................................................................................................... 121 295 12.8.4 LogEvents ........................................................................................................................................ 122 296
12.9 Distributed Energy Resources Function Set .............................................................................................. 122 297 12.9.1 Overview ......................................................................................................................................... 122 298 12.9.2 Terminology and Conventions ......................................................................................................... 123 299 12.9.3 List Ordering .................................................................................................................................... 124 300 12.9.4 Application Guidelines / Behavior ................................................................................................... 124 301
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 10 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
12.9.5 DER Client Device Requirements ..................................................................................................... 127 302 12.9.6 LogEvents ........................................................................................................................................ 129 303
12.10 Metering Mirror ................................................................................................................................... 129 304 12.10.1 Overview ......................................................................................................................................... 129 305 12.10.2 List Ordering .................................................................................................................................... 129 306 12.10.3 Application Guidelines / Behavior ................................................................................................... 129 307 12.10.4 LogEvents ........................................................................................................................................ 131 308
13 Manufacturer – Specific Proprietary Extensions ........................................................................................ 132 309 13.1 Overview .................................................................................................................................................. 132 310 13.2 xmDNS/DNS-SD ........................................................................................................................................ 132 311 13.3 URIs .......................................................................................................................................................... 132 312 13.4 Resources ................................................................................................................................................. 132 313 13.5 DeviceCapabilities Resource ..................................................................................................................... 133 314
14 Appendix A - Web-Application Description Language (INFORMATIVE) ...................................................... 134 315 14.1 Support Resources Section ....................................................................................................................... 134 316
14.1.1 Device Capability Function Set ........................................................................................................ 134 317 14.1.2 Self Device Resource Function Set .................................................................................................. 134 318 14.1.3 End Device Resource Function Set .................................................................................................. 134 319 14.1.4 Function Set Assignments Function Set .......................................................................................... 135 320 14.1.5 Subscription/Notification Mechanism Function Set........................................................................ 135 321 14.1.6 Response Function Set .................................................................................................................... 136 322
14.2 Common Resources Section ..................................................................................................................... 137 323 14.2.1 Time Function Set ............................................................................................................................ 137 324 14.2.2 Device Information Function Set ..................................................................................................... 137 325 14.2.3 Power Status Function Set .............................................................................................................. 138 326 14.2.4 Network Status Function Set ........................................................................................................... 138 327 14.2.5 Log/Event Log Function Set ............................................................................................................. 140 328
14.3 Smart Energy Resources Section .............................................................................................................. 140 329 14.3.1 Configuration Resource Function Set .............................................................................................. 140 330 14.3.2 Software Download Function Set .................................................................................................... 141 331 14.3.3 Demand Response and Load Control Function Set ......................................................................... 141 332 14.3.4 Metering Function Set ..................................................................................................................... 142 333 14.3.5 Pricing Function Set ......................................................................................................................... 144 334 14.3.6 Messaging Function Set ................................................................................................................... 145 335 14.3.7 Billing Function Set .......................................................................................................................... 146 336 14.3.8 Prepayment Function Set ................................................................................................................ 149 337 14.3.9 Flow Reservation Function Set ........................................................................................................ 151 338 14.3.10 Distributed Energy Resources Function Set .................................................................................... 151 339
15 Appendix B – SEP 2 Model (INFORMATIVE) ............................................................................................... 155 340 15.1 SEP 2 Package .......................................................................................................................................... 155 341
15.1.1 DeviceCapability Package ................................................................................................................ 155 342 15.1.2 Common Package ............................................................................................................................ 156 343 15.1.3 EndDevice Package .......................................................................................................................... 175 344 15.1.4 FunctionSetAssignments Package ................................................................................................... 178 345 15.1.5 Pub-Sub Package ............................................................................................................................. 179 346 15.1.6 Response Package ........................................................................................................................... 181 347 15.1.7 Time Package ................................................................................................................................... 183 348 15.1.8 DeviceInformation Package ............................................................................................................. 184 349 15.1.9 PowerStatus Package ...................................................................................................................... 187 350
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 11 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
15.1.10 NetworkStatus Package ................................................................................................................... 189 351 15.1.11 LogEvents Package .......................................................................................................................... 194 352 15.1.12 Configuration Package ..................................................................................................................... 196 353 15.1.13 SoftwareDownload Package ............................................................................................................ 198 354 15.1.14 DRLC Package .................................................................................................................................. 201 355 15.1.15 Metering Package ............................................................................................................................ 205 356 15.1.16 Pricing Package ................................................................................................................................ 212 357 15.1.17 Messaging Package .......................................................................................................................... 216 358 15.1.18 Billing Package ................................................................................................................................. 218 359 15.1.19 Prepayment Package ....................................................................................................................... 223 360 15.1.20 FlowReservation Package ................................................................................................................ 228 361 15.1.21 DER Package .................................................................................................................................... 230 362 15.1.22 Links Package ................................................................................................................................... 246 363
16 Appendix C – Examples and Guidelines [INFORMATIVE] ........................................................................... 252 364 16.1 Registration: Remote ............................................................................................................................... 252 365 16.2 Registration: Local .................................................................................................................................... 255 366 16.3 Discovery: Function Set Assignment ......................................................................................................... 258 367 16.4 Discovery: Without Function Set Assignment........................................................................................... 260 368 16.5 Discovery: Undirected Without Function Set Assignment ........................................................................ 262 369 16.6 Subscription / Notification ....................................................................................................................... 263 370 16.7 Demand Response: General ..................................................................................................................... 266 371 16.8 Demand Response: Cancel ....................................................................................................................... 270 372 16.9 Distributed Energy Resource: General ...................................................................................................... 272 373 16.10 Metering: Reading ............................................................................................................................... 276 374 16.11 Metering: Interval ................................................................................................................................ 281 375 16.12 Metering: Instantaneous ..................................................................................................................... 287 376 16.13 Metering: Mirroring ............................................................................................................................. 290 377 16.14 Pricing: Time of Use ............................................................................................................................. 303 378 16.15 Billing: Billing Period ............................................................................................................................ 309 379 16.16 Billing: Historical .................................................................................................................................. 312 380 16.17 Billing: Projection ................................................................................................................................. 315 381 16.18 File Loading .......................................................................................................................................... 317 382 16.19 Flow Reservation: General ................................................................................................................... 320 383 16.20 Flow Reservation: Cancel ..................................................................................................................... 324 384 16.21 Event Randomization ........................................................................................................................... 328 385
16.21.1 Simple Event .................................................................................................................................... 328 386 16.21.2 Event with Positive Randomized Duration ...................................................................................... 329 387 16.21.3 Event with Positive Randomized Start ............................................................................................ 329 388 16.21.4 Event with Negative Randomized Start ........................................................................................... 330 389 16.21.5 Event with Positive Randomization and Finishing in one Hour ....................................................... 331 390 16.21.6 Event with Negative Randomized Start and at Least One Hour Duration ....................................... 331 391 16.21.7 Event with Randomized Start and Long Ramp Up ........................................................................... 332 392 16.21.8 Event with Positive Randomized Start and Fixed End Time ............................................................ 333 393
17 Appendix D – Guidelines [INFORMATIVE] ................................................................................................. 334 394 17.1 Pricing Implementation Guidelines .......................................................................................................... 334 395
17.1.1 Implementing Common Tariff Designs ............................................................................................ 334 396 17.1.2 Flat Rate Design ............................................................................................................................... 334 397 17.1.3 Time-of-Use Rate Design ................................................................................................................. 335 398 17.1.4 Consumption-based Block Rate Design ........................................................................................... 336 399
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 12 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
17.1.5 Combined Time-of-Use and Consumption-based Block Rate Design .............................................. 336 400 17.1.6 Coordinated and Uncoordinated Pricing and Metering Servers ..................................................... 338 401
17.2 PEV Implementation Guidelines (subject to work with SAE and ISO / IEC) .............................................. 339 402 403
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 13 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
List of Tables 404 Table 7-1 HTTP Headers. .......................................................................................................................................... 36 405 Table 8-1 Local Registration Attributes. ................................................................................................................... 43 406 Table 8-2 Local Registration Descriptor Entry. ......................................................................................................... 43 407 Table 8-3 ACL Attributes. .......................................................................................................................................... 44 408 Table 8-4 AccessDescriptor Entry. ............................................................................................................................ 44 409 Table 8-5 SpecificIDDescriptor Entry. ....................................................................................................................... 45 410 Table 8-6 Example ACL for EndDeviceList. ................................................................................................................ 47 411 Table 8-7 Example ACL entry for EndDevice at point of registration. ...................................................................... 47 412 Table 8-8 Example local registration entry for registering device. ........................................................................... 48 413 Table 8-9 Example ACL entry for EndDevice at point of client access. ..................................................................... 48 414 Table 8-10 Example SpecificIDDescriptor for EndDevice at point of client access. .................................................. 48 415 Table 8-11 Attribute values for Default Security Policy. ........................................................................................... 53 416 Table 8-12 Security LogEvents. ................................................................................................................................. 56 417 Table 8-13 TLS Authentication Matrix. ..................................................................................................................... 58 418 Table 8-14 SEP 2 Authorization Matrix. .................................................................................................................... 58 419 Table 9-1 TXT record parameters. ............................................................................................................................ 70 420 Table 9-2 Service subtype strings and their corresponding SEP 2 function sets. ..................................................... 72 421 Table 10-1 Function Set List Ordering. ..................................................................................................................... 74 422 Table 10-2 Example LogEvents. ................................................................................................................................ 75 423 Table 10-3 Self Device LogEvents. ............................................................................................................................ 76 424 Table 10-4 End Device List Ordering. ........................................................................................................................ 76 425 Table 10-5 End Device LogEvents. ............................................................................................................................ 77 426 Table 10-6 Function Set Assignments List Ordering. ................................................................................................ 78 427 Table 10-7 Subscription / Notification List Ordering. ............................................................................................... 79 428 Table 10-8 Subscription / Notification LogEvents..................................................................................................... 81 429 Table 10-9 Response List Ordering. .......................................................................................................................... 81 430 Table 10-10 Response Types by Function Set. .......................................................................................................... 82 431 Table 10-11 Response LogEvents. ............................................................................................................................ 85 432 Table 11-1 Time LogEvents. ...................................................................................................................................... 87 433 Table 11-2 Power Status LogEvents. ......................................................................................................................... 88 434 Table 11-3 Network Status List Ordering. ................................................................................................................. 88 435 Table 11-4 Network Status LogEvents ...................................................................................................................... 89 436 Table 11-5 LogEvent List Ordering. ........................................................................................................................... 89 437 Table 11-6 General LogEvents. ................................................................................................................................. 90 438 Table 11-7 Configuration LogEvents. ........................................................................................................................ 91 439 Table 11-8 File Download List Ordering. ................................................................................................................... 91 440 Table 11-9 File Download LogEvents. ....................................................................................................................... 94 441 Table 12-1 Demand Response and Load Control List Ordering. ............................................................................. 102 442 Table 12-2 Metering List Ordering. ......................................................................................................................... 105 443 Table 12-3 Reading Types. ...................................................................................................................................... 108 444 Table 12-4 Metering LogEvents. ............................................................................................................................. 109 445 Table 12-5 Pricing List Ordering. ............................................................................................................................. 111 446 Table 12-6 Pricing LogEvents. ................................................................................................................................. 115 447 Table 12-7 Messaging List Ordering. ...................................................................................................................... 115 448 Table 12-8 Billing List Ordering. .............................................................................................................................. 117 449 Table 12-9 Prepayment List Ordering. .................................................................................................................... 119 450 Table 12-10 Prepayment LogEvents. ...................................................................................................................... 121 451 Table 12-11 FlowReservation List Ordering. ........................................................................................................... 121 452
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 14 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Table 12-12 Flow Reservation LogEvents. .............................................................................................................. 122 453 Table 12-13 Distributed Energy Resources List Ordering. ...................................................................................... 124 454 Table 12-14 Modes and Attributes for Generator Type DERs. ............................................................................... 128 455 Table 12-15 Modes and Attributes for Storage Type DERs. ................................................................................... 129 456 Table 12-16 Metering Mirror List Ordering. ........................................................................................................... 129 457 Table 12-17 Metering Mirror LogEvents................................................................................................................. 131 458 Table 16-1 POX Example: Registration Remote. ..................................................................................................... 252 459 Table 16-2 EXI Example: Registration Remote. ...................................................................................................... 254 460 Table 16-3 POX Example: Registration Local. ......................................................................................................... 256 461 Table 16-4 POX Example: Discovery Function Set Assignment .............................................................................. 258 462 Table 16-5 POX Example: Discovery Without Function Set Assignment. ............................................................... 260 463 Table 16-6 POX Example: Discovery Undirected Without Function Set Assignment. ............................................ 262 464 Table 16-7 POX Example: Subscription / Notification. ........................................................................................... 264 465 Table 16-8 EXI Example: Subscription / Notification. ............................................................................................. 265 466 Table 16-9 POX Example: Demand Response – General. ....................................................................................... 266 467 Table 16-10 POX Example: Demand Response - Cancel. ........................................................................................ 270 468 Table 16-11 POX Example: Distributed Energy Resource - General. ...................................................................... 273 469 Table 16-12 POX Example: Meter Reading. ............................................................................................................ 277 470 Table 16-13 POX Example: Metering Interval. ........................................................................................................ 282 471 Table 16-14 POX Example: Metering Instantaneous. ............................................................................................. 287 472 Table 16-15 POX Example: Meter Mirroring. ......................................................................................................... 291 473 Table 16-16 POX Example: Pricing TOU. ................................................................................................................. 304 474 Table 16-17 POX Example: Billing Period. ............................................................................................................... 309 475 Table 16-18 POX Example: Billing Historical. .......................................................................................................... 312 476 Table 16-19 POX Example: Billing Projection. ......................................................................................................... 315 477 Table 16-20 File Load: Flow Description ................................................................................................................. 318 478 Table 16-21 POX Example: Flow Reservation - General. ........................................................................................ 321 479 Table 16-22 POX Example: Flow Reservation - Cancel ........................................................................................... 325 480 Table 16-23 Ramp Value. ........................................................................................................................................ 328 481 Table 16-24 Event Ramp Time. ............................................................................................................................... 329 482 Table 16-25 Event Start Time. ................................................................................................................................ 330 483 Table 16-26 Event Start Time. ................................................................................................................................ 330 484 Table 16-27 Event Start Time. ................................................................................................................................ 331 485 Table 16-28 Event Start Time. ................................................................................................................................ 331 486 Table 16-29 Event Start Time. ................................................................................................................................ 332 487 Table 17-1 TOU Rate. .............................................................................................................................................. 335 488 Table 17-2 Consumption-based Rates. ................................................................................................................... 336 489 Table 17-3 Tariff Structure. ..................................................................................................................................... 336 490
491
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 15 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
List of Figures 492 Figure 8-1: Example Device Authentication Procedure Using HTTPS Port 443 ........................................................ 51 493 Figure 8-2: Device authentication with registration procedure examples using HTTPS .......................................... 55 494 Figure 8-3: SEP 2 including ZigBee IP deployment .................................................................................................... 57 495 Figure 12-1: Active and Reactive Power Flow Directions as Measured at the DER. ............................................... 124 496 Figure 12-2: Example Volt-VAr Curve and Hysteresis ............................................................................................. 126 497 Figure 12-3: Example Low and High - Voltage Ride Through Curves ...................................................................... 126 498 Figure 13-1: Allowed and Disallowed Extension ..................................................................................................... 132 499 Figure 15-1: Version Information ........................................................................................................................... 155 500 Figure 15-2: DeviceCapability ................................................................................................................................. 155 501 Figure 15-3: Identification ...................................................................................................................................... 156 502 Figure 15-4: Events ................................................................................................................................................. 159 503 Figure 15-5: Programs ............................................................................................................................................ 159 504 Figure 15-6: Error .................................................................................................................................................... 160 505 Figure 15-7: Types .................................................................................................................................................. 162 506 Figure 15-8: Primitive Types ................................................................................................................................... 173 507 Figure 15-9: SelfDevice ........................................................................................................................................... 175 508 Figure 15-10: EndDevice ......................................................................................................................................... 176 509 Figure 15-11: FunctionSetAssignments .................................................................................................................. 178 510 Figure 15-12: Pub-Sub ............................................................................................................................................ 179 511 Figure 15-13: Response .......................................................................................................................................... 181 512 Figure 15-14: Time .................................................................................................................................................. 183 513 Figure 15-15: DeviceInformation ............................................................................................................................ 184 514 Figure 15-16: PowerStatus ..................................................................................................................................... 187 515 Figure 15-17: NetworkStatus .................................................................................................................................. 189 516 Figure 15-18: LogEvents ......................................................................................................................................... 194 517 Figure 15-19: Configuration .................................................................................................................................... 196 518 Figure 15-20: Files ................................................................................................................................................... 198 519 Figure 15-21: DRLC Event ....................................................................................................................................... 201 520 Figure 15-22: Load Shed Availability ....................................................................................................................... 202 521 Figure 15-23: Metering Data .................................................................................................................................. 205 522 Figure 15-24: Metering Data Types ........................................................................................................................ 206 523 Figure 15-25: Metering Mirror ............................................................................................................................... 209 524 Figure 15-26: Metering Mirror Inheritance ............................................................................................................ 210 525 Figure 15-27: Pricing ............................................................................................................................................... 212 526 Figure 15-28: TextMessage ..................................................................................................................................... 216 527 Figure 15-29: Billing ................................................................................................................................................ 218 528 Figure 15-30: Billing Readings ................................................................................................................................. 219 529 Figure 15-31: Prepayment ...................................................................................................................................... 223 530 Figure 15-32: FlowReservation ............................................................................................................................... 228 531 Figure 15-33: DER Info ............................................................................................................................................ 230 532 Figure 15-34: DER Info Types .................................................................................................................................. 231 533 Figure 15-35: DER Program..................................................................................................................................... 231 534 Figure 15-36: DER Curves ....................................................................................................................................... 232 535 Figure 15-37: DER Control ...................................................................................................................................... 233 536 Figure 15-38: DER Control Types ............................................................................................................................ 234 537 Figure 16-1: Remote Registration ........................................................................................................................... 252 538
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 16 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Figure 16-2: Registration Local ............................................................................................................................... 255 539 Figure 16-3: Discovery: Function Set Assignment .................................................................................................. 258 540 Figure 16-4: Discovery Without Function Set Assignment ..................................................................................... 260 541 Figure 16-5: Discovery Undirected Without Function Set Assignment .................................................................. 262 542 Figure 16-6: Subscription / Notification ................................................................................................................. 263 543 Figure 16-7: Demand Response General ................................................................................................................ 266 544 Figure 16-8: Demand Response - Cancel ................................................................................................................ 270 545 Figure 16-9: Distributed Energy Resource: General ............................................................................................... 272 546 Figure 16-10: Meter Reading .................................................................................................................................. 277 547 Figure 16-11: Metering Interval .............................................................................................................................. 282 548 Figure 16-12: Metering Instantaneous ................................................................................................................... 287 549 Figure 16-13: Meter Mirroring ............................................................................................................................... 291 550 Figure 16-14: Pricing Time of Use ........................................................................................................................... 304 551 Figure 16-15: Billing Period ..................................................................................................................................... 309 552 Figure 16-16: Billing Historical ................................................................................................................................ 312 553 Figure 16-17: Billing Projection ............................................................................................................................... 315 554 Figure 16-18: File Load - FlowDiagram ................................................................................................................... 317 555 Figure 16-19: Flow Reservation: General ............................................................................................................... 320 556 Figure 16-20: Flow Reservation: Cancel ................................................................................................................. 324 557 Figure 16-21: Simple Event - No Ramp Up - No Ramp Down ................................................................................. 328 558 Figure 16-22: Event with Positive Randomization Duration ................................................................................... 329 559 Figure 16-23: Event with Positive Randomization Start ......................................................................................... 330 560 Figure 16-24: Event with Negative Randomized Start ............................................................................................ 330 561 Figure 16-25: Positive Randomization in an Hour .................................................................................................. 331 562 Figure 16-26: Event with Negative Start in One Hour ............................................................................................ 331 563 Figure 16-27: Randomized Start and Long Ramp Up .............................................................................................. 332 564 Figure 16-28: Randomized Start and Fixed End Time ............................................................................................. 333 565 566
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 17 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
1 Introduction 567
1.1 Purpose 568
The purpose of this document is to define the application protocol used by the Smart Energy Profile 569 release 2.0. The Smart Energy Profile Application Protocol 2.0 is designed to meet the requirements 570 stated in the Smart Energy Profile 2.0 Marketing Requirements Document (SEP 2 MRD) [ZB 09-5162] 571 and the Smart Energy Profile 2.0 Technical Requirements Document (SEP 2 TRD) [ZB 09-5449]. Per 572 Req[DataModel-1], this application protocol is an IEC 61968 common information model [61968] 573 profile, mapping directly where possible, and using subsets and extensions where needed, and follows a 574 RESTful architecture [REST]. 575
1.2 Scope 576
With respect to the OSI network model, the Smart Energy Profile 2.0 Application Protocol is built using 577 the four layer Internet stack model. This specification defines the 'APPLICATION' layer with TCP/IP 578 providing functions in the 'TRANSPORT' and 'INTERNET' layers. Depending on the physical layer in 579 use (e.g., 802.15.4, 802.11, 1901), a variety of lower layer protocols may be involved in providing a 580 complete solution. Generally, lower layer protocols are not discussed in this document except where there 581 is a direct interaction with the application protocol. The scope of this document is defining the 582 mechanisms for exchanging application messages, the exact messages exchanged including error 583 messages, and the security features used to protect the application messages. 584
1.3 Context Overview 585 The Smart Energy Profile 2.0 Application Protocol is proposed to the ZigBee Alliance and the HomePlug 586 Powerline Alliance to meet the needs specified in the SEP 2 MRD and TRD. The Smart Energy Profile 587 2.0 has been identified as a "standard for implementation" in NIST's Framework and Roadmap for Smart 588 Grid Interoperability Standards [NIST 1108]. As such, this document may be useful for anyone 589 developing a Smart Grid solution. 590
All statements and descriptions made in this document on Smart Energy Profile, SEP, or SE are 591 references to the Smart Energy Profile 2.0 Application Profile. 592
1.4 Document Organization 593 The following documents comprise the definition of SEP 2 and all SEP 2 devices will be required to 594 maintain compliance to these documents: 595
� SEP 2 Application Protocol Specification (this document) 596 � SEP 2 XML Schema Definition (XSD) (sep.xsd in [ZB 13-0201]) 597 � SEP 2 WADL (sep_wadl.xml in [ZB 13-0201]) 598
599 The SEP 2 XSD contains the definitions of the SEP 2 resources, attributes, and elements as well as their 600 textual descriptions. The SEP 2 WADL contains the recommended URI structures and use of HTTP 601 methods associated with these objects. In addition a SEP 2 UML model (also contained in 602 [ZB 13-0201]) has been utilized in the creation of the SEP 2 XSD. The SEP 2 UML model is an 603
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 18 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
informative document. Informative textual extracts of the SEP 2 XSD and the SEP 2 WADL are 604 contained in this document for convenience. 605
1.5 Requirement Language 606
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 607 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document, when capitalized 608 and in a normative section, constitute normative text and are to be interpreted as described in [RFC 2119]. 609
1.6 Typography Conventions Used 610
Example URIs, protocol requests, protocol responses, and XML are presented in fixed-width Courier New 611 font, with a size of 8. 612
1.7 Design Principles 613 As per the ZigBee Smart Energy Profile 2.0 Technical Requirements Document (TRD) [ZB 09-5449] 614 Section 10.1, Smart Energy Profile 2.0 will follow a RESTful architecture [REST]. The TRD lists a large 615 number of general design principles. Several specific ones are important for the application protocol: 616
� While devices MAY maintain state, interfaces SHOULD be stateless. 617
� URI structure SHOULD be clear but as efficient as possible. 618
� Minimize the number of transactions required to achieve a given function. 619
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 19 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
2 Acknowledgements 620
On behalf of the ZigBee Alliance, the HomePlug Powerline Alliance, and all of our liaison partners, we 621 would like to extend our thanks to all who participated in the development of this specification. 622 Representatives from many organizations have participated in weekly calls, face-to-face meetings, email 623 exchanges, and specialized editing sessions. Without the broad support from both member and external 624 organizations that care about the development of smart energy solutions, this work would not have been 625 possible. Select individuals stand out for their contributions to this document. 626
When this document was released, the Smart Energy Profile 2 Working Group leadership was composed 627 of the following members: 628
Robby Simpson: Chair 629
Tim Gillman: Vice-chair 630
Jeff Shudark: Secretary 631
Don Sturek: Program Manager 632
Tobin Richardson: ZigBee Alliance Chairman and CEO 633
Steven Van Ausdall: Model, XSD, and WADL Editor 634
Al Petrick: Application Specification Editor 635
Our special thanks to the following members who contributed to the document:636
Casey Anderson 637
Skip Ashton 638
Dan Bailey 639
Gary Birk 640
Donald Bowen 641
Doug Burman 642
Paul Carreon 643
Stephen Chasko 644
Michael Cowan 645
Robert Cragie 646
Wayne Dennison 647
Yusuke Doi 648
Jeff Drake 649
Paul Duffy 650
Ed Eckert 651
Gene Falendysz 652
Matthew Gillmore 653
Tom Herbst 654
Lance Hester 655
Ken Holbrook 656
Shawn Hu 657
Rajagopal Iyengar 658
Jeffrey King 659
David Kravitz 660
Chris Leclercq 661
Kerry Lynn 662
Zahra Makoui 663
Tony Mauro 664
Ricardo Montano 665
Tim Moses 666
Leslie Mulder 667
Don Olsen 668
Ivan O'Neill 669
Barry Peirce 670
Joseph Reddy 671
Emil Romascanu 672
David Smith 673
Michael StJohns 674
Michael Stuber 675
Mark Ward 676
677
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 20 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
3 Document Revision History 678
679
Revision Version Description
00 2.0 Smart Energy Profile 2
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 21 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
4 References 680
External references in this document are tagged with a document reference identifier placed inline within 681 the text. The references section maps these identifiers to document titles and provides hyperlinks to where 682 the source document may be obtained. Please note, not all referenced documents are freely available. 683 Selected documents may require a membership, subscription, or fee to obtain. 684
4.1 Smart Energy 2.0 Documents 685
[ZB 09-5162] ................ ZigBee + HomePlug Joint Working Group Smart Energy Profile Market 686 Requirements Document (09-5162). 687 http://www.zigbee.org/Standards/ZigBeeSmartEnergy/HomePlugMarketingRequ688 irementDocument.aspx 689
[ZB 09-5449] ................ Smart Energy Profile Technical Requirements Document (09-5449). 690 http://www.zigbee.org/Standards/ZigBeeSmartEnergy/20TechnicalRequirements691 Doc.aspx 692
[ZB 13-0201] ................ Smart Energy 2.0 UML Model (13-0201). 693
4.2 IEC Documents 694
[61850] .......................... Communication networks and systems in substations - ALL PARTS 695 (http://webstore.iec.ch). 696
[61968] .......................... Application integration at electric utilities - System interfaces for distribution 697 management – ALL PARTS (http://webstore.iec.ch). 698
4.3 IETF Documents 699
[RFC 768] ..................... User Datagram Protocol (http://tools.ietf.org/html/rfc768). 700
[RFC 793] ..................... Transmission Control Protocol (http://tools.ietf.org/html/rfc793). 701
[RFC 1630] ................... Universal Resource Identifiers in WWW (http://tools.ietf.org/html/rfc1630). 702
[RFC 1738] ................... Uniform Resource Locators (http://tools.ietf.org/html/rfc1738). 703
[RFC 1808] ................... Relative Uniform Resource Locators (http://tools.ietf.org/html/rfc1808). 704
[RFC 2119] ................... Key words for use in RFCs to Indicate Requirement Levels 705 (http://tools.ietf.org/html/rfc2119). 706
[RFC 2560] ................... X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – 707 OCSP, IETF, M. Meyers et al, June 1999, (http://tools.ietf.org/html/ /rfc2560). 708
[RFC 2616] ................... Hypertext Transfer Protocol - HTTP/1.1 (http://tools.ietf.org/html/rfc2616). 709
[RFC 2717] ................... Registration Procedures for URL Scheme Names 710 (http://tools.ietf.org/html/rfc2717). 711
[RFC 2818] ................... HTTP Over TLS (http://tools.ietf.org/html/rfc2818). 712
[RFC 2863] ................... The Interface MIB (https://tools.ietf.org/html/rfc2863). 713
[RFC 3535] ................... IAB Network Management Workshop (http://tools.ietf.org/html/rfc3535). 714
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 22 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
[RFC 3635] ................... Definitions of Management Objects for the Internet-Like Interface Types 715 (http://tools.ietf.org/html/rfc3625). 716
[RFC 4108] ................... Using Cryptographic Message Syntax (CMS) to Protect Firmware, 717 IETF, R. Housley, April 2005, (http://tools.ietf.org/html/rfc4108). 718
[RFC 4193] ................... Unique IPv6 Unicast Addresses (http://tools.ietf.org/html/rfc4193). 719
[RFC 4291] ................... IP Version 6 Addressing Architecture (http://tools.ietf.org/html/rfc4291). 720
[RFC 4293] ................... Management Information Base for the Internet Protocol (IP) 721 (http://tools.ietf.org/html/rfc4293). 722
[RFC 5246] ................... Transport Layer Security (TLS) Protocol V1.2 723 (http://tools.ietf.org/html/rfc5246). 724
[RFC 5280] ................... Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation 725 List (CRL) Profile, IETF, D Cooper et al, May 2008, 726 (http://tools.ietf.org/html/rfc5280). 727
[RFC 5480] ................... Elliptic Curve Cryptography Subject Public Key Information, IETF, S. Turner 728 et al., March 2009, (http://tools.ietf.org/html/rfc5480). 729
[RFC 6550] ................... RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks 730 (http://tools.ietf.org/html/rfc6550). 731
[RFC 6554] ................... An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-732 Power and Lossy Networks (RPL) (http://tools.ietf.org/html/rfc6554). 733
[RFC 6762] ................... Multicast DNS (http://tools.ietf.org/html/rfc6762). 734
[RFC 6763] ................... DNS Based Service Discovery (http://tools.ietf.org/html/rfc6763). 735
[I-D AESCCM] ............. AES-CCM ECC Cipher Suites for TLS (https://docs.zigbee.org/zigbee-736 docs/dcn/12/docs-12-0462-00-SEP 2-aes-ccm.pdf). 737
[I-D XMDNS] ............... Extended Multicast DNS (https://docs.zigbee.org/zigbee-docs/dcn/12/docs-12-738 0461-00-SEP 2-xmdns.pdf). 739
4.4 Other References 740 [ASN.1] ......................... ITU-T Recommendation X.680 – Information technology – Abstract Syntax 741
Notation One (ASN.1): Specification of basic notation, ITU, July 2002. 742
[CSEP] .......................... Consortium for SEP 2 Interoperability (http://www.csep.org). 743
[DOCSIS] ...................... DOCSIS (http://cablelabs.com/cablemodem/specifications/index.html). 744
[EPRI] ........................... Common Functions for Smart Inverters. EPRI, Palo Alto, CA: 2011. Product ID 745 Number 1023059 746 (http://my.epri.com/portal/server.pt?space=CommunityPage&cached=true&pare747 ntname=ObjMgr&parentid=2&control=SetCommunity&CommunityID=221&Pa748 geIDqueryComId=0). 749
[EXI] ............................. Efficient XML Interchange (EXI) Format 1.0 (http://www.w3.org/TR/2008/WD-750 exi-20080919/). 751
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 23 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
[EXIBP] ........................ Efficient XML Interchange (EXI) best practices (http://www.w3.org/TR/exi-best-752 practices/). 753
[Fielding] ...................... Fielding, Roy Thomas (2000), "Architectural Styles and the Design of Network-754 based Software Architectures", Doctoral Dissertation, University of California, 755 Irvine (http://www.ics.uci.edu/~fielding/pubs/dissertation/top.html). 756
[IEEE 802.1AR] ............ Standard for Local and Metropolitan Area Networks: Secure Device Identity, 757 IEEE, 2009 (http://www.ieee802.org/1/pages/802.1ar.html). 758
[ISO 4217] .................... Codes for the representation of currencies and funds 759 (http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumb760 er=46121). 761
[Linux] .......................... Linux (https://www.linux.com/). 762
[NIST–1108] ................. NIST framework and roadmap for Smart Grid Interoperability Standards, Release 763 1.0. 764 (http://collaborate.nist.gov/twikisggrid/pub/SmartGrid/IKBFramework/NISTFra765 meworkAndRoadmapForSmartGridInteroperability_Release1final.pdf). 766
[NIST SP800-131A] ..... Transition: Recommendation for Transitioning the Use of Cryptographic 767 Algorithms and Key Lengths (http://csrc.nist.gov/publications/nistpubs/800-768 131A/sp800-131A.pdf). 769 770
[NIST SP800-131B] ...... Transition: Validation of Transitioning Cryptographic Algorithm and Key 771 Lengths (http://csrc.nist.gov/publications/drafts/800-131B/draft-SP800-772 131B_February2011.pdf). 773 774
[NIST SP800-131C] ...... Transitions: Validating the Transition from FIPS 1862 to FIPS 1863 775 (http://csrc.nist.gov/publications/drafts/800-131C/draft-SP800-776 131C_February2011.pdf). 777 778
[PEN] ............................ Internet Authority Assignment numbers (IANA) PEN 779 (http://pen.iana.org/pen/PenApplication.page). 780 781
[REST] .......................... Representational State Transfer 782 (http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm). 783 784
[SunSpec] ...................... SunSpec Alliance Inverter Control Model, work in progress. 785 (http://www.sunspec.org/specifications/). 786 787
[WADL] ........................ Web Application Description Language (http://www.w3.org/Submission/wadl/). 788
[XML] ........................... Extensible Markup Language (http://www.w3.org/TR/REC-xml/). 789
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 24 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
5 Definitions, Acronyms and Abbreviations 790
5.1 Acronyms and Abbreviations 791
This subsection provides a list of acronyms and abbreviations introduced in this document. For a 792 comprehensive treatment of acronyms and abbreviations used, please refer to Section 4 of the Smart 793 Energy Profile Technical Requirements Document [ZB 09-5449]. 794
ACL .......... Access Control List 795
CA ............. Certificate Authority 796
CRL ........... Certificate Revocation List 797
CSEP ......... Consortium for SEP 2 Interoperability 798
DER .......... Distributed Energy Resource 799
DNS .......... Domain Name System 800
DNS-SD .... DNS-based Service Discovery 801
DRLC ........ Demand Response and Load Control 802
ECDSA ..... Elliptic Curve Digital Signature Algorithm 803
EMS .......... Energy Management System 804
ESI ............ Energy Services Interface 805
EVSE ........ Electric Vehicle Supply Equipment 806
EXI ............ Efficient XML Interchange 807
HTTP ........ Hypertext Transfer Protocol 808
IETF .......... Internet Engineering Task Force 809
IP ............... Internet Protocol 810
LFDI ......... Long Form Device Identifier 811
MCA ......... Manufacturer's CA 812
MICA ........ Manufacturing Issuing CA 813
OCSP ........ Online Certificate Status Protocol 814
OID ........... Object Identifier 815
PKI ............ Public Key Infrastructure 816
REST ......... Representational State Transfer 817
SERCA...... Smart Energy Root CA 818
SFDI .......... Short Form Device Identifier 819
TCP ........... Transmission Control Protocol 820
UOM ......... Units of Measure 821
URI ........... Uniform Resource Identifier 822
XML ......... Extensible Markup Language 823
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 25 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
WADL ...... Web Application Description Language 824
5.2 Definitions 825
A limited set of terms specific to this application specification are introduced below. For a 826 comprehensive treatment of the terms used, please refer to Section 4 of the Smart Energy Profile 827 Technical Requirements Document [ZB 09-5449]. 828
ACCESS CONTROL LIST 829
A security mechanism in which entities and authorizations (e.g., read, write, create, delete) 830 are related to resources to determine the entities' allowed operations on the resources. 831
CERTIFICATE AUTHORITY 832
An entity that issues digital certificates for use by other entities. 833
CERTIFICATE CHAIN 834
A chain of certificates, with each certificate's signature verified using the key from the next 835 certificate in the chain. The single exception is the certificate at the end of the chain (the 836 trust anchor), known as the root CA certificate, which is self signed. 837
CLIENT 838
The device or host that interacts with a server to obtain information related to a resource 839 hosted by the server. 840
DEVICE CERTIFICATE 841
A digital certificate installed within a device that binds the device identity to the device. 842 Device Certificates are exchanged by network access control and application protocols to 843 authenticate devices as genuine SEP 2 and further to prove specific device identity. 844
ENERGY SERVICES INTERFACE (ESI) 845
A device, with multiple network interfaces, which is a member of both the home smart 846 energy network and a service provider's private network. This is the primary mechanism for 847 the service provider to contribute data and directives into the smart energy network and to 848 receive responses from smart energy devices. 849
FINGERPRINT 850
This is the result of summarizing a certificate with a secure hash function. The fingerprint is 851 generally expressed as a hex string. It is used to confirm the integrity of a certificate 852 obtained over an untrusted channel. 853
FUNCTION SET 854
A logical grouping of resources that cooperate to implement SEP 2 features (e.g., Metering, 855 Demand Response and Load Control). 856
FUNCTION SET ASSIGNMENTS 857
A logical addressing mechanism in SEP 2 that allows devices to be directed to use specific 858 resources (e.g., to facilitate a device's participation in a program). Please see Section 10.5 859 for details. 860
HOST 861
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 26 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
This is the representation of a device in its application context. Typically represented by an 862 IP address or domain name. 863
INTERMEDIATE CA 864
A CA below the root CA that issues certificates to subordinate CA's. 865
ISSUING CA 866
A CA that issues certificates to devices or code-signers. 867
MANUFACTURER'S CA (MCA) 868
An Intermediate CA operated by a specific manufacturer for the purpose of issuing MICA's 869 for that manufacturer. 870
MANUFACTURING ISSUING CA (MICA) 871
An Issuing CA that issues certificates to devices during the manufacturing process. 872
MANUFACTURING PKI 873
The set of CAs that issue certificates to devices during the manufacturing process. The set 874 includes the Smart Energy Root CA, Manufacturer's CA's and Manufacturing Issuing CA's. 875
NODE 876
This is the representation of a device in its network context, typically represented as an IP 877 address. 878
OID 879
Object identifier. An OID consists of a node in a hierarchically-assigned namespace, 880 formally defined using the ITU-T's ASN.1 standard [ASN.1]. 881
PEM FORMAT CERTIFICATE 882
An X.509 certificate that has been Base64 encoded and wrapped in "-----BEGIN 883 CERTIFICATE-----","-----END CERTIFICATE-----"sentinels for transport as a text file or 884 block. 885
PKI 886
Public Key Infrastructure. A set of hardware, software, people, policies, and procedures 887 needed to create, manage, distribute, use, store, and revoke digital certificates. 888
REGISTERED 889
The state of a device with regards to a particular server wherein an EndDevice record for the 890 device has been populated on the server and that record contains a valid registration record. 891 These records are typically populated with device information transmitted out-of-band to the 892 server's owner. 893
RESOURCE 894
URI addressable object that is manipulated via the RESTful uniform interface. 895
RESOURCE DISCOVERY 896
The process whereby Clients identify Resources being served on the network. Clients issue 897 a request to all devices on the network requesting resource(s) of interest. Servers hosting the 898 requested resource(s) respond with information necessary to access the Server and its 899 resource(s). 900
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 27 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
ROOT CA 901
A CA whose certificate or public key is a trust anchor for any other certificates in a chain of 902 trust. 903
ROOT CERTIFICATE 904
The Root CA's self-signed certificate. Generally also a Trust Anchor. 905
SELF-SIGNED CERTIFICATE 906
A certificate whose issuer and subject are identical, and whose public key verifies its 907 signature. 908
SERVER 909
The device or host that holds a resource and exposes representations of that resource. 910
SMART ENERGY ROOT CA (SERCA) 911
The top-level CA for the SEP 2 Manufacturing PKI. 912
TRUST ANCHOR 913
The root of trust for a certificate chain. This is an authoritative entity represented by a public 914 key and associated data and is generally provided in the SEP 2 hierarchy in the form of a 915 self-signed certificate. 916
TRUSTED ROOT STORE 917
An integrity-protected location for storing root certificates. 918
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 28 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
6 Design Pattern 919
6.1 Protocol Flexibility 920
The Smart Energy Profile is designed to implement a REST architecture. It is built around the core 921 actions of GET, HEAD, PUT, POST, and DELETE (as used in [REST]), with the addition of a 922 lightweight subscription mechanism as discussed in Section 10.6. Any application protocol that can 923 implement a RESTful command set could likely be used with SEP 2, but HTTP is a required baseline 924 for interoperable SEP 2 implementations. HTTP utilizes TCP as its transport protocol. As a result, TCP 925 manages the session providing delivery assurance and windowing. 926
Smart Energy Profile 2.0 servers and clients SHALL be compliant with [RFC 2616]. 927
6.2 General Rules / Best Practices 928
This specification shall not make distinctions between servers, clients, or devices, when defining 929 interfaces and URIs. The goal is to avoid having a resource that has one behavior on a server and a 930 different behavior on a client or different type of server. The distinction between the server and client 931 role depends on whether a device exposes a resource (server) or interacts with the resource (client). 932
The default mechanism for obtaining a resource representation is a pull mechanism, implemented with 933 GET. A client requests and retrieves data from a server or creates, modifies, or deletes data on a server. 934
The use of a subscription mechanism for retrieving a resource representation is also optionally 935 supported, where convenient and appropriate. Resources that support subscription are denoted by their 936 subscribable attribute. 937
Objects have a defined granularity and whole objects (not partial objects) are to be updated with the 938 granularity defined in the schema. 939
Clients that expect to have intermittent connections to the network (e.g., battery-powered sleepy devices, 940 mobile devices, etc.) use a pull mechanism as their default behavior for resource retrieval, as a 941 subscription / notification mechanism may not be reliable. It should be noted that clients that expect to 942 have intermittent connections to the network may still POST, PUT, and DELETE resources, provided 943 they have the appropriate security permissions. 944
The TCP ports used for HTTP or HTTPS SHALL be specified in the xmDNS service advertisement for 945 the service. 946
Content SHALL be transferred with either one of the content types: "application/sep+xml" or 947 "application/sep-exi". 948
Devices do not assume the use of the URIs and their structures given throughout this specification. All 949 resources are self-describing as it is acknowledged that URIs, schemas, and resources might change in 950 the future. All resources SHALL contain links to their subordinate resources to support flexibility in 951 URIs and future extensibility. Thus, to allow for extensibility and granularity, all objects are described 952 in schemas and referenced via URIs. The URIs presented throughout this specification are 953 recommendations. Thus, clients do not assume that URIs for resources are fixed on all servers or even 954 on a given server (over time), but rather retrieve the appropriate URIs through resource discovery and 955 links within resources. For network efficiency, devices MAY assume URIs are fixed on a particular 956 server over time. If a URI returns an unexpected result, the client SHOULD execute resource discovery 957 to determine the new URI value. 958
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 29 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Version information should not be presented in the URI unless that version information is inherent to the 959 name of that resource. If necessary and for reasons of extensibility, version information is provided 960 within the associated resources and / or schemas. 961
All values in XML and EXI SHOULD be represented as compactly as possible. Decimal values 962 SHOULD be represented without leading zeros. Hexadecimal values SHALL be represented with one 963 leading zero, if needed, to ensure an even number of digits. 964
6.3 WADL 965
The SEP 2 RESTful interface is defined using the Web Application Description Language (WADL) 966 [ZB 13-0201]. 967
Smart Energy Profile 2.0 devices SHALL conform to the interface specifications contained in the 968 WADL as follows. 969
� Devices SHALL conform to the WADL specification as per [WADL]. 970 � Devices SHALL conform to the WADL definition in [ZB 13-0201]. By implication, all resource 971
representations SHALL validate per the schema [ZB 13-0201] within the standardized SEP 972 XML namespace (http://zigbee.org/sep). 973
� Compliance (MODE) designations are interpreted as follows. 974 o Mandatory ("M") - Devices MUST implement and conform. 975 o Optional ("O") - Devices MAY implement, and if implemented, MUST conform. 976 o Discouraged ("D") - Devices SHOULD NOT implement, but if implemented, MUST 977
conform. 978 o Error ("E") - Devices MUST return one of the specified response status codes (e.g. 400 979
– Bad Request or 405 – Method Not Allowed). 980
6.4 Schema 981
� Resources located at URIs returned in the href attribute of "Link" specializations (e.g., 982 EndDeviceListLink, SelfDeviceLink) SHALL conform to the schema definition for that object, 983 which is the tag name with the "Link" suffix removed. For example, the resource at 984 SelfDeviceLink href follows the definition for the SelfDevice resource. 985
� If a client PUTs or POSTs a resource to a server containing attributes or elements that instead 986 are to be populated by the server (e.g., href), the server SHALL return an HTTP 400 error. 987
� If a function set is not implemented, Link elements to resources in that function set SHALL 988 NOT be included. 989
6.5 Uniform Resource Identifiers 990
HTTP uses ASCII text for transferring URIs between clients and servers, as well as for including 991 options and details regarding the message content. These transfers occur with every transaction. If the 992 naming scheme used for URIs is overly verbose, these transactions become needlessly inefficient on 993 constrained networks. Of course, if the naming scheme used is overly cryptic, the advantages of a text-994 based protocol are lost, and it becomes difficult for someone troubleshooting to decipher a transaction. 995
The following conventions are used for URI naming: 996
1) URI elements are at most 4 characters, but recognizable to a knowledgeable engineer. 997 Element names as short as 1 character are acceptable provided their meaning is clear. 998
2) URI elements are constructed of consonants only, unless inclusion of a vowel adds clarity, 999 such as a leading vowel or well-known abbreviation. 1000
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 30 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
3) URI elements are in all lower case. 1001
4) URIs SHALL NOT be greater than 255-bytes in length. In practice, URIs SHOULD be 1002 much smaller than 80-bytes. 1003
6.6 List Resources 1004
Many resources within this specification are derived from the <List> object. Throughout this 1005 specification, these resources will collectively be referred to as list resources. 1006
The following attributes are defined for list resources: 1007
� all – used to indicate the total number of items (subordinate resources) that exist in the list 1008 resource. This number may vary according to the client's access privileges. 1009
� results – used to indicate the number of items (subordinate resources) included in a specific 1010 subset of the list (result from a paged GET query to the list, etc.). This value will always be less 1011 than or equal to 'all'. 1012
Clients and servers use these attributes, combined with the query string parameters described below, to 1013 implement paged access to lists. Client control of list paging is important for resource-constrained 1014 devices. 1015
List items (subordinate resources) are read using one of the two idioms described below: 1016
1) Ordinal access to the first, second, nth, etc. item in the list is supported via query string 1017 parameters included with a GET to the list resource URI. 1018
2) Random access to specific list items is supported via a GET directly to the URI of the list item. 1019
Some list items may be written by POSTing a list item representation to the URI of the list. (e.g., 1020 notifications), while others may be created using private interfaces over the provider network. Ordinal 1021 placement of the new resource within the list is determined by the list sort order (defined by each list). 1022
Each function set defined in this specification that contains list resources includes a List Ordering table. 1023 Each list resource has an entry in the corresponding table that describes the details of one or more 1024 unique sort keys and the precedence of those keys. A list resource's elements SHALL be ordered 1025 according to this specified List Ordering. 1026
6.6.1 Query String Parameters 1027
Query string parameters are parameters added to a URI to provide filtering / paging of list items returned 1028 in query results. 1029
The list paging mechanism allows GET requests to specify the range of list items to be returned in a 1030 query result set. The general syntax of a paged query is as follows: 1031
{URI}?s={x}&a={y}&1={z} 1032
Where {URI} represents a URI used to address a list resource, (s | a | 1) represent query string 1033 parameters (further defined below), and {x}, {y}, and {z} represent the respective query string 1034 parameter values. 1035
The query string parameters are defined as: 1036
� s – ("start") is used to indicate the first ordinal position in the list to be returned in the query 1037 result list as determined by the list's ordering. The value is specified in decimal. The first ordinal 1038 position of the list SHALL be designated with a value of '0' and the maximum possible value is 1039 '65535'. If this query string parameter is not specified, the default start value SHALL be '0'. 1040
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 31 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
� a – ("after") is used to indicate that only items whose primary key occurs after the given date / 1041 time parameter should be included in the query result list. This query string parameter is only 1042 applied to list resources that are ordered using a time-based primary key. The parameter SHALL 1043 be ignored if the primary key is not time-based. The format of the parameter SHALL be a 64-bit 1044 decimal number with identical semantics as that of the TimeType (see Section 12.2 and the 1045 XML XSD in [ZB 13-0201]). 1046
� l – ("limit") is used to set the maximum number of list items (up to 255) to be included in the 1047 query result list. The value is specified in decimal. If this query string parameter is not specified, 1048 the default limit SHALL be '1'. Servers MAY return a result list smaller than that specified by 1049 the client provided limit. 1050
If both a "start" and "after" query string parameter are used simultaneously, the "after" query string 1051 parameter SHALL have precedence. The "start" position 0 SHALL be relative to the position specified 1052 by the "after" parameter. 1053
If a query string requests a list element that does not exist (e.g., s=3 when there are two items in the list), 1054 servers SHALL return an empty list representation. 1055
Readers should note that the "after" query string parameter SHOULD NOT be used alone for paging 1056 through a list. As some list resources MAY contain multiple subordinate resources with the same time-1057 based primary key, it is RECOMMENDED that clients wishing to paginate a list resource while using 1058 the "after" query string parameter should keep the value for the "after" query string parameter constant 1059 while changing the "start" query string parameter. 1060
If a particular query string parameter appears more than once, then the first occurrence of the query 1061 string parameter SHALL be used (in left-to-right order) and subsequent occurrences MUST be ignored. 1062
Server receipt of a query parameter unknown to the server MUST be ignored by the server and MUST 1063 NOT generate an HTTP error. Servers MUST NOT generate resource representations containing href 1064 attributes that contain query parameters. Clients MUST ignore query parameters contained in resource 1065 hrefs, but SHOULD NOT remove them if the URI is used for subsequent RESTful exchanges. 1066
Should an empty list representation be requested (either through the use of query string parameters such 1067 as l=0 or when the list itself is empty), the server SHALL return no subordinate representations, but 1068 SHALL return any other elements that may be defined for the list. 1069
Clients MUST NOT assume any index semantics for list URIs. For example, a client desiring to read the 1070 3rd item from the list at http://some-host/somelist MUST NOT assume a GET to http://some-1071 host/somelist/2 will return the third item. The correct access is supported by the client issuing a GET to 1072 http://some-host/somelist?s=2&l=1. 1073
The following examples demonstrate the use of query string parameters with a list resource. Consider 1074 the MyTypeList resource, depicted below: 1075
<MyTypeList href="http://host1/the/list" all="7" results="7"> 1076 <MyType href="http://host1/instance/of/type/red"> 1077 <timeStamp>100</timeStamp> 1078 </MyType> 1079 <MyType href="http://host2/instance/of/type/green"> 1080 <timeStamp>200</timeStamp> 1081 </MyType> 1082 <MyType href="http://host3/instance/of/type/blue"> 1083 <timeStamp>300</timeStamp> 1084 </MyType> 1085 <MyType href="http://host4/instance/of/type/yellow"> 1086 <timeStamp>400</timeStamp> 1087 </MyType> 1088 <MyType href="http://host5/instance/of/type/black"> 1089 <timeStamp>500</timeStamp> 1090 </MyType> 1091
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 32 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
<MyType href="http://host6/instance/of/type/white"> 1092 <timeStamp>600</timeStamp> 1093 </MyType> 1094 <MyType href="http://host7/instance/of/type/orange"> 1095 <timeStamp>700</timeStamp> 1096 </MyType> 1097 </MyTypeList> 1098 1099
This list is sorted in ascending order per the <timeStamp/> element of MyType. 1100
A GET to http://host1/the/list?s=0&l=1 will return: 1101 1102 <MyTypeList href="http://host1/the/list" all="7" results="1"> 1103 <MyType href="http://host1/instance/of/type/red"> 1104 <timeStamp>100</timeStamp> 1105 </MyType> 1106 </MyTypeList> 1107 1108 A GET to http://host1/the/list?s=0&l=5 will return: 1109 1110 <MyTypeList href="http://host1/the/list" all="7" results="5"> 1111 <MyType href="http://host1/instance/of/type/red"> 1112 <timeStamp>100</timeStamp> 1113 </MyType> 1114 <MyType href="http://host2/instance/of/type/green"> 1115 <timeStamp>200</timeStamp> 1116 </MyType> 1117 <MyType href="http://host3/instance/of/type/blue"> 1118 <timeStamp>300</timeStamp> 1119 </MyType> 1120 <MyType href="http://host4/instance/of/type/yellow"> 1121 <timeStamp>400</timeStamp> 1122 </MyType> 1123 <MyType href="http://host5/instance/of/type/black"> 1124 <timeStamp>500</timeStamp> 1125 </MyType> 1126 </MyTypeList> 1127 1128 A GET to http://host1/the/list?s=5&l=1 will return: 1129 1130 <MyTypeList href="http://host1/the/list" all="7" results="1"> 1131 <MyType href="http://host6/instance/of/type/white"> 1132 <timeStamp>600</timeStamp> 1133 </MyType> 1134 </MyTypeList> 1135 1136 A GET to http://host1/the/list?s=5&l=5 will return: 1137 1138 <MyTypeList href="http://host1/the/list" all="7" results="2"> 1139 <MyType href="http://host6/instance/of/type/white"> 1140 <timeStamp>600</timeStamp> 1141 </MyType> 1142 <MyType href="http://host7/instance/of/type/orange"> 1143 <timeStamp>700</timeStamp> 1144 </MyType> 1145 </MyTypeList> 1146 1147 A GET to http://host1/the/list?s=12&l=2 will return a list representation containing 0 items: 1148 1149 <MyTypeList href="http://host1/the/list" all="7" results="0"> 1150 </MyTypeList> 1151 1152 or <MyTypeList href="http://host1/the/list" all="7" results="0" /> 1153 1154 1155
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 33 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
A GET to http://host6/instance/of/type/white will return: 1156
<MyType href="http://host6/instance/of/type/white"> 1157
<timeStamp>600</timeStamp> 1158 </MyType> 1159 1160 A GET to http://host1/the/list?a=400&l=4 will return: 1161 1162 <MyTypeList href="http://host1/the/list" all="7" results="3"> 1163 <MyType href="http://host5/instance/of/type/black"> 1164 <timeStamp>500</timeStamp> 1165 </MyType> 1166 <MyType href="http://host6/instance/of/type/white"> 1167 <timeStamp>600</timeStamp> 1168 </MyType> 1169 <MyType href="http://host7/instance/of/type/orange"> 1170 <timeStamp>700</timeStamp> 1171 </MyType> 1172 </MyTypeList> 1173 1174 A GET to http://host1/the/list?a=400&s=0&l=2 will return: 1175 1176 <MyTypeList href="http://host1/the/list" all="7" results="2"> 1177 <MyType href="http://host5/instance/of/type/black"> 1178 <timeStamp>500</timeStamp> 1179 </MyType> 1180 <MyType href="http://host6/instance/of/type/white"> 1181 <timeStamp>600</timeStamp> 1182 </MyType> 1183 </MyTypeList> 1184 1185 A GET to http://host1/the/list?a=400&s=2&l=2 will return: 1186 1187 <MyTypeList href="http://host1/the/list" all="7" results="1"> 1188 <MyType href="http://host7/instance/of/type/orange"> 1189 <timeStamp>700</timeStamp> 1190 </MyType> 1191 </MyTypeList> 1192
6.7 Resource Design Rules 1193
The following rules apply to the design and use of list resources: 1194
� List resources SHALL support "start" and "limit" query string parameters, thus always 1195 supporting paging. 1196
� List resources that have a time-based primary key SHALL support the "after" query string 1197 parameters. 1198
� All subordinate resources of list resources SHALL include an href attribute containing the URI 1199 of the subordinate resource. 1200
� Each list resource described in this specification includes a List Ordering that defines how the 1201 list is ordered, including the details of one or more keys used to order the list and the precedence 1202 of these keys. 1203
� When queried, list resources SHALL return subordinate resources in the order defined by the 1204 List Ordering. 1205
� All subordinate resources of list resources that support multiple types, e.g., NotificationList, 1206 SHALL include an xsi:type attribute. In this case, the XML Schema Instance Namespace must 1207 also be declared. See Section 16 for examples. 1208
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 34 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
The following rules apply to the design and use of non-list resources: 1209
� Non-list resources SHALL NOT support the defined query string parameters. Query string 1210 parameters applied to non-list resource URIs SHOULD be ignored. 1211
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 35 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
7 Application Support 1212
7.1 Overview 1213
This section details the standards-based application transport protocol and other lower-layer 1214 requirements required for interoperability of SEP 2 devices. 1215
The application support layer provides the following services: 1216
� RESTful HTTP/1.1 as the application data exchange semantics, as described in [RFC 2616] and 1217 [Fielding]. 1218
� XML [XML] and / or EXI [EXI] encoding as the data payload of the RESTful operations. 1219
� Transport authentication and encryption using TLS over HTTP [RFC 2818] and [RFC 5246]. 1220
7.2 Use of TCP 1221
The choice of HTTP/1.1 as the application data exchange protocol leads directly to the use of TCP as the 1222 transport protocol. [RFC 2616] states that: 1223
"HTTP communication usually takes place over TCP / IP connections. The default port is TCP 80 1224 [19], but other ports can be used. This does not preclude HTTP from being implemented on top of 1225 any other protocol on the Internet, or on other networks. HTTP only presumes a reliable transport; 1226 any protocol that provides such guarantees can be used; the mapping of the HTTP/1.1 request and 1227 response structures onto the transport data units of the protocol in question are outside the scope of 1228 this specification." 1229
Hence, albeit that other transport protocols may be used to carry HTTP, they are required to provide 1230 reliable transport. Clearly, the de facto choice is TCP [RFC 793]. 1231
7.3 URI Encoding 1232
The address of the resources presented by an SEP 2 host will use the standard URI syntax specific to 1233 HTTP/1.1 (i.e., http://) as per [RFC 1630], [RFC 1738], and [RFC 1808]. 1234
It is recommended that SEP 2 use the formally defined and registered (IANA) URN namespace 1235 definitions to address its application level resources as referenced in [RFC 2717] and [RFC 1808]. 1236
Given the constrained nature of many SEP 2 hosts, it is critical to devise the URL namespace scheme 1237 (hierarchy) that is both descriptive and compact. For more information, see Section 6.5. 1238
7.4 HTTP Headers 1239
HTTP/1.1 defines a variety of header types that have the potential to be verbose. As an example, the 1240 Accept header is illustrated below showing lengths varying from 35 octets to 106 octets: 1241
� Accept: audio/*; q=0.2, audio/basic (35 octets) 1242
� Accept: text/*; q=0.3, text/html; q=0.7, text/html; level=1, text/html; level=2; q=0.4, 1243 */*; q=0.5 (92 octets) 1244
� Accept: text/xml, application/xml, application/xhtml+xml, text/html; q=0.9, text/plain; 1245 q=0.8, image/png, */*; q=0.5 (106 octets) 1246
Given the packet size constraints for many SEP 2 networks, the set of HTTP headers supported must be 1247 curtailed through best practices recommendations realizing that a host cannot prevent a verbose message 1248 from being sent to it. 1249
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 36 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
SEP 2 provides a set of Mandatory, Optional, and Discouraged recommendations for each HTTP header. 1250 SEP 2 implementations SHOULD employ only Mandatory HTTP headers, minimize the use of Optional 1251 HTTP headers, and avoid the use of Discouraged headers. 1252
7.4.1 HTTP Header Field Recommended Usage 1253
In the following table, the HTTP/1.1 header fields have been annotated with the following labels: 1254
� MANDATORY: support for the field is REQUIRED. 1255
� OPTIONAL: support for this field is left to the implementer's discretion. 1256
� DISCOURAGED: to conserve code space and / or bandwidth, support for this field, while not 1257 explicitly forbidden, is not recommended. 1258
The following table summarizes the recommended use of HTTP/1.1 headers in SEP 2: 1259
Table 7-1 HTTP Headers. 1260
Header Used in Message Type RFC Required / Optional
SEP 2 Use
Accept Request Optional Mandatory
Accept-Charset Request Optional Discouraged
Accept-Encoding Request Optional Discouraged
Accept-Language Request Optional Discouraged
Accept-Ranges Request Response Optional Discouraged
Age Response Optional (Required for a cache) Discouraged
Allow Response Required Mandatory
Authorization Request Response Optional Discouraged
Cache-Control Request Response Optional Discouraged
Connection Request
Optional (Required in some situations (e.g., HTTP/1.1 applications that do not support persistent connections))
Optional (Mandatory in some situations)
Content-Encoding Response Optional (Required when an encoding is applied)
Discouraged
Content-Language Response Optional Discouraged
Content-Length Request Response
Optional (Required in many situations, see section 4.4 of [RFC 2616])
Optional (Mandatory in many situations, see section 4.4 of [RFC 2616])
Content-Location Response Optional Discouraged
Content-MD5 Response Optional Discouraged
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 37 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Header Used in Message Type RFC Required / Optional
SEP 2 Use
Content-Range Response Optional Optional (see Section 11.7.1.4)
Content-Type Request Response Required Mandatory
Cookies Optional Discouraged
Date Request Response Mandatory Mandatory
ETag Response Optional Optional (see Section 11.7.1.4)
Expect Request Optional Discouraged
Expires Response Optional Discouraged
From Request Optional Discouraged
Host Request Required Mandatory
If-Match Request Optional Discouraged
If-Modified-Since Request Optional Discouraged
If-None-Match Request Optional Discouraged
If-Range Request Optional Discouraged
If-Unmodified-Since Request Optional Discouraged
Last-Modified Response Optional Discouraged
Location Response Optional Mandatory in many
situations (e.g., POST responses)
Max-Forwards Request Optional Discouraged
Pragma Request Response Optional Discouraged
Proxy-Authenticate Response Optional Discouraged
Proxy-Authorization Request Optional Discouraged
Range Request Optional Optional (see Section 11.7.1.4)
Referrer Request Optional Discouraged
Retry-After Response Optional Optional (see Section 11.7.1.4)
Server Response Optional Discouraged
TE Request Discouraged Discouraged
Trailer Response Discouraged Discouraged
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 38 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Header Used in Message Type RFC Required / Optional
SEP 2 Use
Transfer-Encoding Response Optional Discouraged
Upgrade Request Optional Discouraged
User-Agent Request Optional Discouraged
Vary Response Discouraged Discouraged
Via Request Response Optional Discouraged
Warning Request Response Discouraged Discouraged
WWW-Authenticate Response Optional Discouraged
7.5 HTTP Response Codes 1261
Response codes are expected to be generalized across RESTful platforms. The specific uses detailed 1262 below are likely to be generalized. In the interest of clarity and completeness, they are included here. 1263 Please note that these response codes follow general best practices for RESTful interfaces, though they 1264 are tuned to address some of the limitations of the embedded space. 1265
This sub-section attempts to highlight HTTP response codes that are felt to be more important or that 1266 need special attention from developers. However, SEP 2 clients may encounter any HTTP response code 1267 defined by [RFC 2616] and, all use of, and response to HTTP response codes SHALL be specification 1268 and RFC compliant. 1269
7.5.1 Common Responses 1270
The following HTTP response codes are those considered to be of utmost importance for this 1271 specification. 1272
7.5.1.1 1xx (Informational) 1273
These response codes are informational in purpose and are used to indicate that the server is continuing 1274 to process in some fashion. 1275
[RFC 2616] states, "A client MUST be prepared to accept one or more 1xx status responses prior to a 1276 regular response, even if the client does not expect a 100 (Continue) status message. Unexpected 1xx 1277 status responses MAY be ignored by a user agent." 1278
7.5.1.2 200 ("OK") 1279
This response code is sent to indicate a successful transaction. 1280
This response code is often used in response to a successful GET request, with the entity-body 1281 containing a representation of the requested resource. Use of this response code in response to PUT, 1282 POST, or DELETE requests is discouraged, to avoid the potentially unnecessary traffic generated by 1283 returning the resource representation in the entity-body (see 201 ("Created") and 204 ("No Content")). 1284
7.5.1.3 201 ("Created") 1285
This response code is sent to indicate a new resource has been created, at the client's request with a PUT 1286 or POST. 1287
The Location header SHALL be used in conjunction with this response code to indicate the URI of the 1288 newly created resource. The inclusion of a representation of the newly created resource in the entity-1289 body of the response is discouraged, to conserve bandwidth. 1290
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 39 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
[RFC 2616] states, "If a new resource is created, the origin server MUST inform the user agent via the 1291 201 (Created) response." 1292
7.5.1.4 204 ("No Content") 1293
This response code is sent to indicate a successful transaction, but one where the response does not 1294 include an entity-body. 1295
This response code is often used in response to a successful PUT or POST request, where the resource is 1296 modified, not created. This response code is also sent in response to a successful DELETE request. This 1297 response code is also sent in response to a successful GET request, where the resource exists but has an 1298 empty representation. 1299
Further, when there are URIs that point to a resource that does not yet have content (an "empty 1300 representation"), this response code SHOULD be returned. For instance, if a client created a new 1301 resource with a POST and that new resource contains URIs pointing to resources that were not yet 1302 created and then a client were to request those linked resources, this response code would be the best 1303 response. When those resources are created (via a PUT, for instance), this response code (204) 1304 SHOULD be returned (in response to the PUT, for instance). 1305
7.5.1.5 206 ("Partial Content") 1306
This response code is sent to indicate the server has fulfilled the partial GET request (as specified by the 1307 Range header) for a resource. Note that [RFC 2616] requires the Content-Range and Date headers 1308 MUST be present in the response. 1309
7.5.1.6 301 ("Moved Permanently") 1310
This response code is sent to indicate that the requested resource has a new URI. The Location header 1311 SHOULD be used in conjunction with this response code to indicate the new URI of the requested 1312 resource. The entity-body of the response SHOULD be empty. Upon unexpected receipt of this response 1313 code, clients SHOULD perform resource discovery to determine which resources have changed location. 1314
7.5.1.7 302 ("Redirect") 1315
The Location header SHALL be used in conjunction with this response code to indicate the new URI of 1316 the requested resource. The entity-body of the response SHOULD be empty. 1317
This response code is often used to redirect URI's requested as HTTP to HTTPS. 1318
7.5.1.8 400 ("Bad Request") 1319
This response code is used to indicate a client-side error and is used when no other 4xx response code is 1320 appropriate. Often, this response code indicates that the representation sent by a client with a PUT or 1321 POST is not appropriate or is malformed. 1322
[RFC 2616] states, "All Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) 1323 status code to any HTTP/1.1 request message which lacks a Host header field." 1324
7.5.1.9 401 ("Unauthorized") 1325
This response code is used when a client does not have proper authorization to perform the requested 1326 action on a resource. 1327
Note, if a server did not wish a client to know of the existence of the resource, it should instead send a 1328 404 ("Not Found") response code. 1329
[RFC 2616] states, "The response MUST include a WWW-Authenticated header field containing a 1330 challenge applicable to the requested resource." 1331
7.5.1.10 404 ("Not Found") 1332
This response code is used to indicate that no resource can be found at the specified URI. 1333
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 40 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
This response code MAY also be used in lieu of a 401 response code. 1334
7.5.1.11 405 ("Method Not Allowed") 1335
This response code is used to indicate that the resource does not allow the HTTP method used by the 1336 client. 1337
[RFC 2616] states, "The response MUST include an Allow header containing a list of valid methods for 1338 the requested resource." 1339
7.5.1.12 406 ("Not Acceptable") 1340
This response code is used to indicate that a server is unable to generate a response that is acceptable 1341 according to the Accept headers sent in the request. 1342
7.5.1.13 413 ("Request Entity Too Large") 1343
This response code is used to indicate that a server is refusing to process a request, as the request is 1344 larger than the server is willing or able to process. 1345
7.5.1.14 416 ("Requested Range Not Satisfiable") 1346
This response code is used to indicate that a server has received a Range request that does not overlap 1347 any of the resource content. 1348
[RFC 2616] states "A server sending a response with status code 416 (Requested range not satisfiable) 1349 SHOULD include a Content-Range field with a byte-range-resp-spec of "*". The instance-length 1350 specifies the current length of the selected resource. A response with status code 206 (Partial Content) 1351 MUST NOT include a Content-Range field with a byte-range-resp-spec of "*". 1352
7.5.1.15 417 ("Expectation Failed") 1353
This response code is used to indicate that an expectation given in an Expect request-header field cannot 1354 be met by the server or that the server does not support the given expectation. 1355
[RFC 2616] states, "If a server receives a request containing an Expect field that includes an 1356 expectation-extension that it does not support, it MUST respond with a 417 (Expectation Failed) status." 1357
7.5.1.16 500 ("Internal Server Error") 1358
This response code is used to indicate that the server has an internal problem and is a generic server 1359 error response. 1360
7.5.1.17 501 ("Not Implemented") 1361
This response code is used when a client attempts to use a feature of HTTP (such as a method) that the 1362 server does not support. 1363
[RFC 2616] states, "The recipient of the entity MUST NOT ignore any Content - (e.g., Content-Range) 1364 headers that it does not understand or implement and MUST return a 501 (Not Implemented) response 1365 in such cases." 1366
7.5.1.18 503 ("Service Unavailable") 1367
This response code is used when a server, due to a temporary overload condition, is unable to service a 1368 request. 1369
7.5.2 Minimal Understanding 1370
Should a client wish to operate with minimal understanding of HTTP response codes, it need only 1371 examine the first digit of the response code to understand the general category of the response and "treat 1372 any unrecognized response as being equivalent to the x00 status code of that class, with the exception 1373 that an unrecognized response MUST NOT be cached." [RFC 2616]. 1374
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 41 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
7.6 Application Payload Syntax 1375
Application payload message encoding using both XML [XML] and EXI [EXI] SHALL be supported 1376 by all servers. Application payload message encoding using either XML [XML] or EXI [EXI] SHALL 1377 be supported by all clients. 1378
7.6.1 XML Encoding 1379
The XML declaration is optional as per [XML] and SHOULD NOT be included in SEP 2 transactions, 1380 to reduce packet sizes. The XML version used SHALL be 1.0. For XML payloads, the encoding 1381 SHALL be UTF-8. 1382
7.6.2 EXI Encoding 1383
The options for encoding EXI documents SHALL be as follows, and transactions will likely fail if 1384 different options are declared in the EXI option header. Options marked as (default) are EXI 1385 specification [EXI] defaults and SHOULD NOT be specified explicitly. 1386
� Non-strict schema-informed grammar with the schema [ZB 13-0201] 1387
� Alignment is bit-packed (default) 1388
� Compression is false (default) 1389
� Strict is false (default) 1390
� Fragment is false (default) 1391
� Preserve options are all false (default) 1392
� selfContained is false (default) 1393
� schemaId is "S0" (two bytes: 0x53, 0x30, without quotes). This schemaId corresponds to the 1394 normative schema of SEP 2.0 [ZB 13-0201]. 1395
� datatypeRepresentationMap is not used (default) 1396
� valueMaxLength is unbounded (default) 1397
� valuePartitionCapacity is unbounded (default) 1398
� No user defined meta-data 1399
The following XML document describes the EXI option header that SHALL be used to encode the 1400 messages. 1401
<header xmlns="http://www.w3.org/2009/exi"> 1402 <common><schemaId>S0</schemaId></common> 1403 </header> 1404
7.7 Content Negotiation 1405
A client SHALL declare acceptable media types using the HTTP Accept header. 1406
7.7.1 Schema Version Negotiation 1407
When specifying an "application/sep-exi" media type, an extensibility level ("level") SHALL be 1408 specified in the HTTP Accept header for schema version negotiation. "level" is an Accept-extension 1409 defined in [RFC 2616]. The extensibility level specified using an HTTP Accept header supersedes an 1410 extensibility declaration discovered during resource discovery (see Section 9.3). 1411
The Extensibility Level defines the base schema and its capability for arbitrary extension. The 1412 Extensibility Level is one of "-S0" or "+S0". The S0 indicates the base schema version: SEP 2. "-S0" 1413
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 42 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
indicates the node does not accept arbitrary tags that are not defined in the base schema, and "+S0" 1414 indicates it accepts arbitrary tags. A node with "-S0" will likely fail on an EXI document using arbitrary 1415 types, elements, and attributes that are not defined in the schema used for encoding. Devices SHALL 1416 NOT send messages to nodes that declare "-S0" using arbitrary types, elements, and attributes. 1417
The grammar used for EXI SHALL be generated as a non-strict grammar only, as having both strict and 1418 non-strict grammars would put a large burden on storage requirements for certain devices. The use of a 1419 non-strict grammar allows for extensions without schema modification. An invalid (i.e., not defined in 1420 the schema) part of an EXI document is allowed in a non-strict grammar and can carry arbitrary tags, 1421 attributes, and text encoded using the built-in grammar. 1422
Due to strict memory constraints, some nodes may not be able to parse invalid parts of an EXI document 1423 encoded using the built-in grammar. To avoid such errors, a node may declare its inability to receive 1424 arbitrary extensions using the "-" (minus) prefix in the Extensibility Level. Alternatively, nodes that 1425 declare the "+" (plus) prefix in the Extensibility Level will be able to parse extended parts of an EXI 1426 document. 1427
Note that the Extensibility Level does not indicate whether the node can process the data, but only 1428 whether it can parse the data. 1429
The format of the Extensibility Level is "(-|+)Sn" where n is a character to describe base schema version 1430 (currently "0"). As extensions of SEP 2.x schemas are intended to be backward compatible, a node that 1431 declares schemaId "S[i]" is intended to be compatible with all versions between "S0" and "S[i]". 1432
For example: 1433 Accept: application/sep-exi; level=-S0 1434 indicates that the client wishes to receive content encoded using EXI where the base schema of the client 1435 is SEP 2 and that the client does not accept arbitrary tags not defined in the schema. 1436
A client SHOULD use the Extensibility Level discovered during resource discovery to determine if a 1437 server accepts non-strict parts of an EXI document prior to initiating PUT / POST operations where the 1438 content contains extended attributes / elements. A server SHOULD use the Extensibility Level specified 1439 in the Accept header to determine if a client accepts non-strict parts of an EXI document prior to 1440 responding to GET operations where the content contains extended attributes / elements. 1441
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 43 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
8 Security 1442
Depending on the underlying physical network, messages may be encrypted at lower layers, in addition 1443 to the security features provided specifically for the application layer. This section describes the security 1444 features that are provided at the application layer and that are REQUIRED for use over all networks. 1445
8.1 Introduction 1446
Securing transactions between clients and servers is based on using HTTP over TLS [RFC 2818] (also 1447 known as HTTPS) using TLS version 1.2 [RFC 5246]. The TLS records are then transported using TCP. 1448 The TLS handshake mechanism provides mutual authentication based on device certificates or self-1449 signed certificates and TLS records provide encryption and message authentication using the AES-CCM 1450 mode of operation. Access control lists allow or deny use of resources based on authentication level and 1451 address information. A registration list is used for authorizing clients. 1452
8.2 Security Attributes 1453
In this section we define some abstract data structures for managing registration (see Section 8.9) and 1454 access control. How this functionality is accomplished is left to the implementer. No access to these data 1455 structures is defined in this specification. 1456
8.2.1 Local Registration Attributes 1457
Local registration attributes represent the data which would be used to hold information passed out-of-1458 band as part of the registration process prior to resources being established. 1459
Table 8-1 Local Registration Attributes. 1460
Attribute Identifier Type Range Description Default
aclLocalRegistration 0x00 List - A table of RegistrationDescriptors each with information for a specific registration
(empty)
aclLocalRegistrationEntries 0x01 Integer Implementation specific
Number of entries in aclRegistration
0
1461
Table 8-2 Local Registration Descriptor Entry. 1462
Name Type Range Description Default
PIN Integer 0 – 999999
6-digit PIN (5 plus check digit) for basic server validation. The PIN is also reflected in the Registration resource linked to the EndDevice resource
-
SFDI SFDI - SFDI of registering device. The SFDI is also reflected in the EndDevice resource
-
DeviceType Integer 0 – 3 Minimum required device type 0
HardwareModuleName String - Optional additional hardware module information
-
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 44 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
8.2.2 Access Control List (ACL) Attributes 1463
Access control list (ACL) attributes represent the data that would be used to hold information to 1464 determine whether access to a particular resource by a particular client is allowed or denied. An ACL 1465 can enforce more granular access control based on various criteria (e.g., client identity). Conceptually, 1466 an ACL exists for every single accessible resource, however in practice it is likely only certain resources 1467 with more complex access policies would require a representation of all the data specified in this 1468 section. 1469
Table 8-3 ACL Attributes. 1470
Attribute Identifier Type Range Description Default
aclDefaultAccess 0x02 Access Descriptor
- Default access to resource
-
aclSpecificID 0x03 List - A list of SpecificIDDescriptors for each specific client access to resource
-
aclSpecificIDEntries 0x04 Integer Implementation specific
Number of entries in aclSpecificID
0
1471
Table 8-4 AccessDescriptor Entry. 1472
Name Type Range Description Default
Method Bitmap 0x0 – 0xf Bitmap of which methods are supported:
0x1: GET
0x2: PUT
0x4: POST
0x8: DELETE
0x10:HEAD
0x0
AuthType Integer 0x0 – 0x0f Bitmap of which authentication types are allowed:
0x1: No authentication
0x2: User authentication
0x4: Self-signed Certificate
0x8: Device Certificate
Remaining bits are reserved for authentication types not defined by this specification but by an additional security policy
0x0
DeviceType Integer 0 – 3 Device type:
0: Unknown
0
1473
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 45 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Table 8-5 SpecificIDDescriptor Entry. 1474
Name Type Range Description Default
Access Access Descriptor
- Access levels required for client -
IPAddr IPAddr - IP Address of client -
Port Integer 0x0000 – 0xffff
Port of client
0: Wildcard (any port)
0
Access control list (ACL) attributes provide a mechanism for granting and revoking privileges to use 1475 specified methods with a particular resource, applicable to all resources described in this specification. 1476 Access control more granular than a resource is out of scope for this specification. The mechanisms for 1477 authentication and the binding of that authentication to a specified identity (such as an IP address) are 1478 specified in Sections 8.5 and 8.6. 1479
ACLs are used to set default privileges and grant additional privileges, not to deny privileges. Thus, if a 1480 given client's request does not explicitly meet the required privilege in the associated ACL, then that 1481 client does not have that privilege. The default configuration of an ACL for a given resource means that 1482 resource is not accessible to clients. In practice, this state only exists ephemerally and all ACLs will be 1483 initialized appropriately at startup according to the security policy and will be subsequently modified 1484 according to registration and authentication. 1485
Subordinate resources created dynamically will initially inherit their ACL from their parent resource. 1486
ACLs may be statically fixed with a default operation for some resources and may be dynamic and 1487 extensible for others. If a resource does not have an ACL, access is granted to the resource 1488 unconditionally. 1489
Initialization of ACLs, beyond minimal requirements, is out of scope for this specification and is 1490 governed by overall security policy. Default settings for ACLs for particular function sets are described 1491 in Section 8.8. 1492
8.2.2.1 aclDefaultAccess 1493
aclDefaultAccess in the ACL is used for settings irrespective of the client identity of an incoming 1494 request and is used initially to authorize an incoming HTTP request. 1495
8.2.2.2 aclSpecificIDList 1496
A SpecificIDDescriptor entry in the aclSpecificIDList part of the ACL is an additional entry used to 1497 allow specific additional checks to be done to authorize based on client identity (IP address and port). 1498
8.2.2.3 Access Authorization 1499
These are controls that are independent of the source identity (IP address and port) and thus can be 1500 configured in both aclDefaultAccess and a SpecificIDDescriptor entry in aclSpecificIDList as shown in 1501 Table 8-4 and Table 8-5. 1502
In the following, 'corresponding ACL entry' means: 1503
� The first SpecificIDDescriptor entry in aclSpecificIDList which matches the incoming client 1504 HTTP request's source IP address and port. 1505
� aclDefaultAccess otherwise 1506
8.2.2.3.1 Method Attribute 1507
The Method attribute is used to control which HTTP request method is allowed for client access. 1508
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 46 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
� GET 1509
� PUT 1510
� POST 1511
� DELETE 1512
The HTTP method of an incoming HTTP request is checked and Method authorization will be TRUE if 1513 the method is allowed in the corresponding ACL entry. 1514
8.2.2.3.2 AuthType Attribute 1515
The AuthType attribute is used to control the required authentication types the client can use in its 1516 incoming HTTP/HTTPS request. 1517
� 0x1: No authentication 1518
� 0x2: User authentication 1519
� 0x4: Self-signed Certificate 1520
� 0x8: Device Certificate 1521
If an incoming HTTP request is destined for the port associated with HTTPS (typically port 443), the 1522 incoming authentication type will be set to the corresponding TLS session authentication type. If an 1523 incoming HTTP request is destined for the port associated with HTTP (typically port 80), the 1524 authentication type will be set to 0x1 (no authentication). The user authentication AuthType (0x02) can 1525 be used if additional user authentication outside of the scope of this specification takes place. 1526
The incoming authentication type is compared with the bitmap in AuthType in the corresponding ACL 1527 entry and AuthType authorization will be TRUE if the corresponding authentication type is set in 1528 AuthType in the corresponding ACL entry. Representing this logically: 1529
if (authentication type & AuthType) != 0: 1530
AuthType authorization = TRUE 1531
else 1532
AuthType authorization = FALSE 1533
8.2.2.3.3 DeviceType Attribute 1534
The DeviceType attribute is used to control the device type required of the client's incoming HTTP 1535 request. It is based on the deviceType OID in the certificate (see Section 8.11.7.1). 1536
If an incoming HTTP request is destined for the port associated with HTTPS, the incoming device type 1537 will be set to the corresponding TLS session device type based on the deviceType OID in the certificate. 1538 If an incoming HTTP request is destined for the port associated with HTTP, the device type will be set 1539 to 0 (unknown). 1540
If the DeviceType in the ACL is set to 0, device type authorization will be TRUE unconditionally. 1541 Otherwise the incoming device type is compared with the DeviceType in the corresponding ACL entry 1542 and DeviceType authorization will be TRUE if the device type is equal to the DeviceType in the 1543 corresponding ACL entry. 1544
8.2.2.4 Authorization Logic 1545
Authorization is granted if Method authorization, AuthType authorization, and DeviceType 1546 authorization are all TRUE. Access to the resource can then take place. 1547
If Method authorization is not granted, the server MAY respond with either: 1548
HTTP/1.1 400 Bad Request 1549
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 47 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Or 1550
HTTP/1.1 405 Method Not Allowed 1551
If AuthType or DeviceType authorization is not granted, the server SHOULD immediately respond: 1552
HTTP/1.1 404 Not Found 1553 The server MAY respond: 1554
HTTP/1.1 401 Unauthorized 1555 Otherwise, processing will continue. 1556
8.2.2.5 ACL Examples 1557
This section contains two informative examples to illustrate the use of ACLs, using EndDeviceList and 1558 EndDevice. 1559
8.2.2.5.1 EndDeviceList 1560
The EndDeviceList resource is usually accessible by any client to find its own entry in the list. 1561 Therefore, the ACL will be as follows: 1562
Table 8-6 Example ACL for EndDeviceList. 1563
Attribute Comment
aclDefaultAccess Method: 0x01 (GET only)
AuthType: 0x1 (no authentication)
Device Type: 0 (unknown)
aclSpecificID Empty
aclSpecificIDEntries 0
In this example, there will never be any SpecificIDDescriptors required, as this resource needs to be 1564 accessible to any device. 1565
8.2.2.5.2 EndDevice 1566
In this example, an EndDevice resource for a client does not exist prior to registration. 1567
The earliest point it can be created is at the point of registration and the ACL would be set as follows: 1568
Table 8-7 Example ACL entry for EndDevice at point of registration. 1569
Attribute Comment
aclDefaultAccess Method: 0x00 (no default access)
AuthType: 0x1 (no authentication)
Device Type: 0 (unknown)
aclSpecificID Empty
aclSpecificIDEntries 0
In this example, there is no default access as only the client device associated with the EndDevice is able 1570 to access the EndDevice. Also, at this point, there has been no client communication therefore there 1571 would be no SpecificIDDescriptor entry in aclSpecificIDList. 1572
There would also be an entry placed in the local registration list corresponding to the client: 1573
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 48 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Table 8-8 Example local registration entry for registering device. 1574
Name Type Range Description Default
PIN Integer 0 – 999999 6-digit PIN (5 plus check digit) of registering device
-
SFDI SFDI 0 - 68719476735, 2^36-1
SFDI of registering device -
DeviceType Integer 0 – 3 Registering device type 0
HardwareModuleName String - Optional additional hardware module information
-
In this state, it is primed to be populated with a SpecificIDDescriptor when the device actually accesses 1575 the EndDeviceList resource. 1576
When the client attempts access to any resource on a function set server using TLS, it will start 1577 performing the TLS handshake, which involves transferring the client's certificate. At the point of 1578 access, if there is a pending registration, it will be checked against the client's device. If there is a match, 1579 and the validated certificate's SFDI matches, the ACL for the EndDevice will be populated with an 1580 additional SpecificIDDescriptor: 1581
Table 8-9 Example ACL entry for EndDevice at point of client access. 1582
Attribute Comment
aclDefaultAccess Method: 0x00 (no default access)
AuthType: 0x1 (no authentication)
Device Type: 0 (unknown)
aclSpecificID One SpecificIDDescriptor for client
aclSpecificIDEntries 1
1583
Table 8-10 Example SpecificIDDescriptor for EndDevice at point of client access. 1584
Name Type Range Description Default
Access Access Descriptor
- Access levels required for client:
Method: 0xF (GET, PUT, POST, DELETE)
AuthType: 0x8 (Device Certificate)
DeviceType: (as appropriate for device)
-
IPAddr IPAddr - IP Address of client -
Port Integer 0x0000 – 0xffff
Port of client 0
8.3 Device Credentials 1585
There are three credentials per device: 1586
� Short Form Device Identifier (SFDI) 1587
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 49 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
� Long Form Device Identifier (LFDI) 1588
� PIN 1589
8.3.1 Certificate Fingerprint 1590
The certificate fingerprint is the result of performing a SHA256 operation over the whole DER-encoded 1591 certificate and is used to derive the SFDI and LFDI. A certificate fingerprint is not confidential and is 1592 never used to derive subsequent keying material. 1593
An example certificate fingerprint used for illustration in the following examples is: 1594
3E4F-45AB-31ED-FE5B-67E3-43E5-E456-2E31-984E-23E5-349E-2AD7-4567-2ED1-45EE-213A 1595
8.3.2 Short-form Device Identifier (SFDI) 1596
The SFDI SHALL be the certificate fingerprint left-truncated to 36-bits. For display purposes, this 1597 SHALL be expressed as 11 decimal (base 10) digits, with an additional sum-of-digits checksum digit 1598 right-concatenated. Based on the example in Section 8.3.1, this would be 167-261-211-391. 1599
Left truncation to 36-bits: 0x3E4F45AB3 1600
Expressed as a decimal: 16726121139 1601
Right-concatenation of check digit and hyphenation: 167-261-211-391 1602
For input validation purposes, the sum of the digits of the fingerprint including the checksum digit, 1603 modulo 10, SHALL be zero. The SFDI has sufficient entropy (236) to uniquely identify the device in the 1604 context of its usage and is used to identify a device within a HAN or site domain. It should not be used 1605 in a truly global context (i.e., where the identity of the device cannot be qualified with the domain it is 1606 in). 1607
For a device with a Device Certificate, the SFDI can be printed on the device packaging. 1608
8.3.3 Long-form Device Identifier (LFDI) 1609
The LFDI SHALL be the certificate fingerprint left-truncated to 160-bits (20 octets). For display 1610 purposes, this SHALL be expressed as 40 hexadecimal (base 16) digits in groups of four. Based on the 1611 example in Section 8.3.1, this would be '3E4F-45AB-31ED-FE5B-67E3-43E5-E456-2E31-984E-23E5'. 1612 The LFDI is used when a globally unique identity is required, for example in sending an event back to a 1613 service provider that is associated with a particular device. 1614
8.3.4 6-digit PIN code 1615
The SDFI and LFDI are derived from public information (i.e., a Certificate), therefore can potentially be 1616 recreated by an eavesdropper. Therefore, a device MAY also have an additional 6-digit PIN code, which 1617 can be shared out-of-band with a service provider in conjunction with the SFDI or LFDI. For display 1618 purposes, this SHALL be expressed as 5 decimal (base 10) digits, with an additional sum-of-digits 1619 checksum digit right-concatenated: 1620
Original PIN: 12345 1621
Right-concatenation of check digit and hyphenation: 123-455 1622
For input validation purposes, the sum of the digits of the PIN including the checksum digit, modulo 10, 1623 SHALL be zero. The PIN MAY be obtainable from the EndDevice server through the Registration 1624 resource to validate that the client is in communication with the correct server. The PIN SHOULD be 1625 configurable on a device where possible for registration purposes, otherwise SHOULD be a random 5-1626 digit value plus check digit pre-programmed into the device and printed on the device. The PIN is not 1627 overly secure and therefore SHALL NOT be used in any way to derive keys for actual data encryption. 1628
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 50 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
8.3.5 Registration Code 1629
The SFDI and PIN are usually presented separately. However, in certain cases it may be convenient to 1630 provide a single registration code, which is simply the concatenation of the SFDI and the PIN expressed 1631 as a decimal (base 10) number: 1632
SFDI || PIN 1633
From the examples above, this would be 167-261-211-391-123-455. 1634
8.4 Resource Access Authentication and Authorization context 1635
A node is able to perform network layer communication once it has been authenticated and authorized to 1636 join the network. However, application layer authentication and authorization MAY be required before 1637 clients and servers can exchange application layer messaging. Registration (see Section 8.9) with a 1638 utility or third party service provider MAY also be needed to provide explicit device and user 1639 authorization at the application layer. 1640
Resource access requiring application layer authentication, data confidentiality and integrity checking 1641 SHALL occur through requests from a client to the server using HTTP over TLS [RFC 2818] (also 1642 known as HTTPS) using TLS version 1.2 [RFC 5246]. Resource access not requiring application layer 1643 authentication, data confidentiality or integrity checking SHALL occur through requests from a client to 1644 the host server using HTTP [RFC 2616]. 1645
If a request is made to the port associated with HTTPS, it is considered an HTTPS request and 1646 authentication SHALL have taken place. If authentication has not taken place, authentication SHALL be 1647 initiated as described in Section 8.5. When authenticated, the request is then passed to the ACL 1648 associated with the resource. Ancillary information about the request obtained from the secure session, 1649 notably the level of client authentication, will also be compared with the ACL. 1650
If the request is made to the port associated with HTTP, it is considered an HTTP request and 1651 authentication SHALL NOT be REQUIRED and the request is then passed to the ACL associated with 1652 the resource. Ancillary information about the request stating the client is unauthenticated will also be 1653 compared with the ACL (see Section 8.2.2.3.2). 1654
Authorization on a request-by-request basis is determined by the ACL settings for the resource, which 1655 may be set up at the end of the authentication based on the level of client authentication. The Local 1656 Registration List (aclLocalRegistrationList) may be additionally used to authorize on a device-by-device 1657 basis. 1658
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 51 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
1659
Figure 8-1: Example Device Authentication Procedure Using HTTPS Port 443 1660
8.5 Resource Access Authentication 1661
Resource access authentication only applies using HTTPS. It may be possible to authenticate at a higher 1662level using authentication based on HTTP-only transactions but this is out of scope for this specification. 1663
The use of TLS [RFC 5246] requires that all hosts implementing server functionality SHALL use a 1664Device Certificate whereby the server presents its Device Certificate as part of the TLS handshake. 1665
The application authentication process is as follows: 1666
1) The resource's server listens on the TCP port associated with HTTPS. 1667
2) The client initiates an HTTP request using a random unused source TCP port to the resource's 1668server using the TCP port associated with HTTPS. 1669
3) If no TLS session is in place, a TLS handshake SHALL occur between the client and server: 1670
a) Authentication of the server SHALL be done as part of the TLS handshake by 1671validating its Device Certificate as described in [RFC 5246], Section 7 using the 1672inherent PKI. If security policy dictates, additional certificate validation MAY be 1673required. 1674
HTTP Request (sp:n, dp:443) GET /<rsrc1>
Authentication
HTTP Response (sp:443, dp:n) 200 OK
ACL initialized according to security policy for clients B and C
Server IP address A
Client IP address B
HTTP Request (sp:n, dp:80) GET /<rsrc1> HTTP Response (sp:80, dp:n) 404 Not Found
Authorization for unsecured access denied based on ACL lookup
Authorization granted for B based on ACL lookup
Client IP address C
HTTP Request (sp:m, dp:443) GET /<rsrc1>
Authentication
HTTP Response (sp:443, dp:m) 200 OK
Authorization granted for C based on ACL lookup
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 52 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
b) If the client has a Device Certificate, authentication of the client SHALL be done as part 1675 of the TLS handshake by validating the client's Device Certificate as described in [RFC 1676 5246], Section 7 using the inherent PKI. If security policy dictates, additional certificate 1677 validation MAY be required. The authentication level to be compared with a resource's 1678 corresponding AuthType attribute will be 0x8 (Device Certificate). 1679
c) If the client has a Self-signed Certificate, the Self-signed Certificate SHALL be 1680 validated for correctness. The authentication level to be compared with a resource's 1681 corresponding AuthType attribute will be 0x4 (Self-signed Certificate). 1682
If the client does not have a certificate and the security policy allows, client authentication MAY NOT 1683 need to take place, or secondary client authentication MAY take place after the TLS handshake. If 1684 secondary client authentication has taken place, the authentication level to be compared with a resource's 1685 corresponding AuthType attribute will be 0x2 (User Authentication). If no client authentication has 1686 taken place, the authentication level to be compared with a resource's corresponding AuthType attribute 1687 will be 0x1 (No authentication). 1688
8.6 Resource Access Authorization 1689
Pre-authorization for resources is normally set when the client registers with the host as described in 1690 Section 8.9. If the security policy allows, authorization MAY occur immediately after authentication 1691 based on implicit rules to allow a request to complete. This is to allow unregistered access to resources 1692 based on security policy. If the client uses a Self-signed Certificate, pre-authorization using the SFDI of 1693 the Self-signed Certificate MUST have taken place and authorization SHALL be granted if the SFDI of 1694 the presented Self-signed Certificate matches the SFDI presented as part of registration. 1695
8.7 Cipher Suites 1696
All devices SHALL support the TLS_ECDHE_ECDSA_WITH _AES_128_CCM_8 cipher suite 1697 [I-D AESCCM]. The ECC cipher suite SHALL use elliptic curve secp256r1. 1698
� All devices acting as a server SHALL support the ECC cipher suite. In particular, all devices 1699 acting as a server SHALL have an ECC certificate. 1700
� All devices acting as a client SHALL support the ECC cipher suite for the purposes of 1701 validating an ECC certificate. 1702
� All devices acting as a client SHOULD support the request for an ECC certificate. 1703
8.8 Default Security Policy 1704
Service providers create security policies by balancing the requirements of their regulatory environment 1705 and the results of their risk assessments. Different regulatory environments may mandate requirements 1706 that trade ease of data access with information assurance. The use of TLS, ACLs, and other security 1707 controls give the service provider the flexibility to meet these needs. Security policies are a combination 1708 of ACL attribute values and additional security controls dictated by the service provider. 1709 Implementation of security policies is out of scope of this specification. For the purpose of certification 1710 testing, the following table represents the default security policy for each function set. Servers SHALL 1711 be configurable to support each default policy for all implemented function sets during certification 1712 testing. 1713
The Function Set column in Table 8-11 reflects the functionsImplemented attribute in 1714 DeviceInformation. 1715
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 53 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Table 8-11 Attribute values for Default Security Policy. 1716
Function Set aclDefaultAccess
AuthType
Device Certificate
needed Registered Device
Device Capability 0xf No No
Self Device Resource 0xc No Yes
End Device Resource 0xc No Yes
Function Set Assignments 0x8 Yes Yes
Subscription / notification mechanism 0x8 Yes Yes
Response 0x8 Yes Yes
Time 0x8 Yes Yes
Device Information 0x8 Yes Yes
Power Status 0x8 Yes Yes
Network Status 0x8 Yes Yes
Log / Event Log 0x8 Yes Yes
Configuration Resource 0x8 Yes Yes
Software Download 0x8 Yes Yes
DRLC 0x8 Yes Yes
Metering 0x8 Yes Yes
Pricing 0xc No Yes
Messaging 0xc No Yes
Billing 0x8 Yes Yes
Prepayment 0x8 Yes Yes
Flow Reservation 0x8 Yes Yes
DER Control 0x8 Yes Yes
1717 The aclDefaultAccess attribute Method value SHOULD match the Allowed Methods for each resource 1718 enumerated in the SEP 2 WADL [ZB 13-0201]. The Method value MUST contain GET (0x01). The 1719 aclDefaultAccess attribute DeviceType value should be 'unknown' (0). Servers SHALL support the 1720 default policies for certification testing. Servers MAY additionally support alternative policies. For 1721
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 54 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
example, to meet regulatory requirements a utility may mandate a policy that provides unauthenticated 1722 pricing information from a pricing server over the port associated with HTTP to any SEP 2 device. 1723 Based on risk assessments, service providers may have differing policies for devices enrolled in high-1724 incentive Demand Response / Load Control programs than those enrolled in low-incentive programs, to 1725 include additional requirements such as DeviceType authorization. Servers SHOULD provide the 1726 functionality to support multiple security policies to meet the requirements of different service 1727 providers. 1728
8.9 Registration 1729
Registration describes the procedure whereby an out-of-band procedure is used to convey client 1730 registration information a priori to the server that houses a resource that will subsequently be accessed 1731 by the client. The registration information is the client's SFDI and optionally, PIN, which uniquely 1732 identifies the client in the given context. 1733
Registration may occur some time before the client attempts to access a resource, for example, using a 1734 web site or telephone to register the information with a service provider. The service provider will then 1735 provide the information to the EndDevice server using some out-of-band mechanism, (e.g., the AMI 1736 network) and the server will program its registration list accordingly. 1737
Alternatively, there may be no actual registration before a client attempts to access a resource and, for 1738 example, the server may present the premises owner with the SFDI of the client attempting access via a 1739 user interface. The premises owner may then continue to authorize the client access, or deny access 1740 based on the information presented from the client's certificate. 1741
This section describes a typical registration procedure for a client using a Device Certificate with an 1742 EndDevice server. 1743
Registration for clients SHALL occur via an EndDevice resource corresponding to the client, which 1744 typically resides on an ESI associated with the utility, premises owner or third party service provider 1745 that is trusted to perform registration. 1746
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 55 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
1747
Figure 8-2: Device authentication with registration procedure examples using HTTPS 1748
8.9.1 EndDeviceList 1749
Clients SHALL locate HAN services by performing DNS Service Discovery (DNS-SD) queries to the 1750HAN, see Section 9 for details. The client can then resolve the URI of the EndDeviceList (given as 1751/edev for illustration purposes) for registration and authentication purposes and know which port(s) the 1752server for the EndDeviceList is listening on. 1753
The EndDeviceList is the resource used by a client to complete the process initiated by registration of 1754the client when the device owner wishes to register the device in a utility, premises owner or service 1755provider program. In some cases, registration MAY be required for access. 1756
Upon registering a client, the EndDevice resource's server aclLocalRegistrationList will be configured 1757with: 1758
� The client SFDI, to be registered in the utility, premises owner or third party service 1759provider program. 1760
� Optionally, the client PIN 1761
� The required device types of the associated client. 1762
Thus, at the point of registration, the EndDevice resource's server is able to perform authentication based 1763on the Device Certificate and additional user authentication based on the client SFDI. 1764
The EndDevice resource's server MAY allow access from clients that have not been pre-configured if 1765the security policy allows. 1766
The registration procedure is as follows: 1767
HTTP Request (sp:m, dp:443) GET /edev
Authentication
HTTP Response (sp:443, dp:m) 200 OK
Out of band registration
ESI IP address A
Client IP address B
HTTP Request (sp:m, dp:443) POST /edev HTTP Response (sp:443, dp:m) 200 OK Note: sp = source port, dp = destination port
Authorization to create /edev instance is granted based on ACL lookup
ACLs setup for /edev and other resources as necessary based on successful authentication and matching registration
Authorization granted based on ACL lookup
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 56 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
1. The EndDevice resource's server SHALL listen on the TCP port associated with HTTPS and 1768 follow the procedure described in [RFC 5246] when a client attempts to access the EndDevice 1769 resource. 1770
2. Authorization SHALL then occur whereby the ACLs of the server resources corresponding to 1771 the registering client are set according to the security policy and the presence in 1772 aclLocalRegistrationList. This ensures that following registration, a client can typically proceed 1773 to access all the resources it is authorized to without having to perform any further procedures. 1774
3. If present, the client MUST verify that the EndDevice's associated Registration resource 1775 contains the correct PIN for the client. If the PIN does not match, the client SHOULD NOT 1776 attempt any further access to that server. 1777
4. The client SHALL subsequently re-use its Device Certificate to authenticate with any other 1778 server host. It does not need to re-authenticate with the EndDevice resource's server. 1779
8.10 Security LogEvents 1780
There are specific LogEvents attributable to security. These will use a function set enumeration of 1781 'security' as defined in the model. These are as follows: 1782
Table 8-12 Security LogEvents. 1783
LogEvent Name LogEvent Code LogEvent Description
SEC_TLS_ALERT 0x00 SHOULD be issued when a TLS Alert is generated. The logEventID SHALL be set to the TLS Alert value [RFC 5246].
SEC_REGISTRATION_MISS 0x01 SHOULD be issued when a received certificate does not have a corresponding SFDI entry in the registration list.
SEC_ACL_ACCESS_FAILED 0x02 SHOULD be issued when access to a resource fails due to failing access control criteria described in Section 8.2.2.
8.11 Certificate Management 1784
8.11.1 Introduction 1785
There is a single agreed-upon Public Key Infrastructure (PKI) in the Smart Energy Profile 2.0 (SEP 2) 1786 certificate management system: the Manufacturing PKI. The Manufacturing PKI issues certificates to 1787 devices at the time of application installation, e.g., at manufacture. These certificates are intended for 1788 use during deployment (or redeployment) and on-going operation to authenticate the device to other 1789 SEP 2 devices implementing SEP 2 applications over TLS. 1790
In addition, this document describes a few other types of certificates that Smart Energy applications may 1791 encounter depending on which services they support – see Section 8.11.8.3 below. While native SEP 2 1792 devices are required to understand, support and process Manufacturing PKI certificates, support of the 1793 additional certificates is optional and generally targeted at specific classes of devices (e.g., Energy 1794 Services Interface (ESI), web portal). 1795
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 57 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
There are 6 classes of certificates that may be active in a SEP 2 system, depending on configuration and 1796 use: 1797
� Device Certificates – Issued under the Manufacturing PKI during manufacturing to purpose-1798 built (aka "native") SEP 2 certified devices for operational purposes. 1799
� Device Test Certificates – Issued under the Manufacturing PKI during manufacturing to 1800 purpose-built (aka "native") SEP 2 certified devices for test purposes. 1801
� Additional Certificates for SEP 2 Devices – One or more OPTIONAL TLS server certificates 1802 issued by non-SEP 2 CAs to SEP 2 devices such as ESI's for use in addition to the Device 1803 Certificate. 1804
� Generic Client Certificate for non-native entities – A TLS client certificate issued by a generic 1805 (non-SEP 2) Certificate Authority to a non-native entity. 1806
� Generic Server Certificate for non-native entities – A TLS server certificate issued by a generic 1807 (non-SEP 2) Certificate Authority to a non-native entity. 1808
� Self-Signed Client Certificate for non-native entities – A TLS client certificate self-generated 1809 and self-signed by a customer or software. 1810
A diagram of a deployed solution based on SEP 2 devices is illustrated in Figure 8-3. 1811
AMI Network
Internet
Tablet or PC[Self-Signed Cert orCommercial Cert]
TThermostat[SE2 Cert]
CBEnergy Services
Interface[SE2 Cert
opt Comm Cert]
UtilityCommercial CertSE2/ZIP
WiFi/Router
SE2/ZIP
SE2/ZIP
WiFi
WiFi
CableFiberDSL
Hard
line
Hardline
AMISE2 over AMI
SE2 overIPv6
SE2 Web Interface
C
BOther EnergyManagement
[SE2 Cert]
Dryer[SE2 Cert]
Dishwasher[SE2 Cert]
SE2/
ZIP
C
BOther EnergyManagement[SE2 Cert or
Commercial Cert]
WiF
i
�� SE2 is Smart Energy (XML) over TLS�� ZIP is Zigbee IP (uses SE2 certs)�� SE2 Cert needed to talk ZIP�� SE2 Manufactured devices ALWAYS have SE2
Cert 1812
Figure 8-3: SEP 2 including ZigBee IP deployment 1813
With the exception of the "AMI Network", the "Internet" and the "Utility", all of the devices pictured 1814 above reside in the customer premises. Devices purpose-built for SEP 2 have a manufactured-in Device 1815 Certificate. Other devices and entities such as the utilities and a customer-owned tablet computer may 1816
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 58 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
use self-signed certificates or may use certificates issued by commercial CAs. Support for those 1817 certificates is mainly dependent on the options implemented by the server. 1818
8.11.2 Certificate Usage – Authentication vs. Authorization 1819
Certificates provide a mechanism to authenticate an identity. Once authenticated (by proving possession 1820 of the associated private key, and by having the certificate chain to a known root of trust), that identity 1821 (or the service, person, or application associated with that identity) can be authorized access to 1822 resources, the ability to assume a role (e.g., system operator, general user) or perform various functions. 1823
An authenticated certificate by itself does not generally grant authorization. Specific applications that 1824 accept the certificate MAY grant implicit authorization to access any resource under the purview of the 1825 application, but usually authorize access based on the identity represented by the certificate (e.g., an 1826 Access Control List entry). The following tables describe both the authentication and authorization uses 1827 of certificates described by this profile. 1828
Table 8-13 describes the mechanisms for certificate validation – the authentication of the identity 1829 claimed in the certificate. Note that for a self-signed certificate, the authentication is limited only to 1830 validating the self-signature over the certificate and that provides only an integrity check. 1831
The phrase "SEP 2 Cert – Indef" is meant to convey that Manufacturing PKI certificates are indefinitely 1832 valid and the check is limited solely to a check of the signatures on the certificate chain. The phrase 1833 "Optional OCSP" means that the server device (and optionally, the client device) may utilize Online 1834 Certificate Status Protocol (OCSP) [RFC 2560] as an additional mechanism to determine if a certificate 1835 has been revoked. OCSP may only be used to verify non-SEP 2 certificates. 1836
Table 8-14 describes the mechanisms for determining if the holder of a specific certificate (and its 1837 private key) may access specific resources. Generically, each resource has an ACL tagged to it. If the 1838 identity of the certificate holder has the appropriate rights to a specific resource, then the representation 1839 of the resource is returned via query. Note that there are certain resources that are accessible to all 1840 authenticated clients. 1841
Table 8-13 TLS Authentication Matrix. 1842
Authentication Server
Native SEP 2 Application
Generic Server Self-Signed
Client Native SEP 2 Application
SEP 2 Cert - Indef Optional OCSP Not Allowed
Generic Client Optional OCSP Not Specified Here Not Specified Here
Self-Signed Signature Validation Not Specified Here Not Specified Here
1843 The above table should be read as describing the authentication on the offered client certificate by the 1844 server. For example – Generic Client / Native SEP 2 Application has an "Optional OCSP" entry 1845 meaning the SEP 2 Application can OPTIONALLY use OCSP to check the validity of the Generic 1846 Client certificate in addition to its normal certificate validation process. 1847
"SEP 2 Cert – Indef" means that if the Smart Energy Manufacturing PKI certificate validly chains to the 1848 Smart Energy root it is considered valid – neither OCSP nor CRLs are used or issued by CAs within the 1849 Manufacturing PKI hierarchy. 1850
Table 8-14 SEP 2 Authorization Matrix. 1851
Authorization Server
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 59 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Native SEP 2 Application
Generic Server Self-Signed
Native SEP 2 Application ACL ACL or Public Resources
(Server specific)
Not Allowed
Generic Client ACL or Public Resources
Not Specified Here Not Specified Here
Self-Signed ACL or Public Resources
Not Specified Here Not Specified Here
1852 The above table should be read as describing the authorization mechanism used by the server with 1853 respect to the offered client credential. For example – the Generic Client/Native SEP 2 Application entry 1854 of "ACL" means that either there is a specific ACL for the generic client credential that permits access 1855 to specific data OR the absence of such ACL allows that generic client access only to public resources. 1856
8.11.3 Manufacturing PKI 1857
This section covers only those certificates issued under the auspices of the Manufacturing PKI. It 1858 specifically excludes the certificates described in Section 8.11.8.3 as "Other Certificates". 1859
The SEP 2 Manufacturing PKI SHALL be a hierarchy with a depth of 2, 3 or 4 levels. At the top level, 1860 Manufacturing PKI hierarchy SHALL have one SERCA. One or more SERCAs SHALL be nominated 1861 by the CSEP [CSEP] and SHALL be out-sourced to a commercial CA service provider. A SERCA is the 1862 property of the CSEP (specifically the private keys associated with the SERCA root are owned by 1863 CSEP) and is operated on the CSEP's behalf by a commercial CA. A commercial CA MAY operate one 1864 or more SERCAs as business needs dictate and this is one possible model for the initial operation of the 1865 SERCAs. A SERCA MAY be moved from one commercial CA to another as business needs dictate. 1866 Private key material for a SERCA MUST be held in a form to allow secure transfer of the material to a 1867 new commercial CA if necessary. The SERCA issues MCA certificates and MICA certificates to 1868 authorized vendors based on CSEP provided policy. The current version of the specification allows a 1869 SEP 2 vendor to contract with a SERCA for the issuance of Device Certificates, but the actual 1870 permission to issue such certificates rests with the CSEP. 1871
A SERCA MAY issue Device Certificates on behalf of one or more manufacturers. 1872
The Manufacturing PKI hierarchy MAY include one SEP 2 MCA. One or more MCAs SHALL be out-1873 sourced to a SEP 2 vendor, specifically for the issuance of vendor-specific MICAs. A SEP 2 vendor 1874 MAY contract with a commercial CA to host the SEP 2 vendor's MCA credentials (certificate and 1875 private key), but retains ownership of such credentials. MCAs may only issue MICA certificates. 1876
The Manufacturing PKI hierarchy MAY include one SEP 2 MICA. One or more MICAs SHALL be 1877 out-sourced to a SEP 2 vendor, specifically for the production of SEP 2 certified devices by that vendor. 1878
All devices SHALL store exactly one SERCA in their certificate path. All devices SHALL include at 1879 least the public keys of all existing SERCAs and MAY include their certificates. In the course of any 1880 particular authentication, any device can therefore verify the chain of signatures leading up to any one of 1881 the roots. 1882
The following certificate paths are the only valid instantiations of the Manufacturing PKI: 1883
� SERCA -> Device Certificate 1884
� SERCA -> MICA -> Device Certificate 1885
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 60 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
� SERCA -> MCA -> MICA -> Device Certificate 1886
8.11.3.1 Manufacturing Certificate Lifecycle 1887
Certificates within the Manufacturing PKI have an indefinite lifetime – this includes, specifically, a 1888 SERCA. Nevertheless, CA certificates may be retired and subsequently replaced when circumstances 1889 dictate. In such cases, the retired certificate and its associated private key SHALL no longer be used for 1890 issuing certificates. However, parties MAY continue to rely upon those certificates for validating 1891 subordinate certificates. If, however, the signature algorithm or parameter set used in a manufacturing 1892 certificate comes to be viewed as insufficiently secure for the purpose, parties MAY retire those 1893 certificates and associated public keys. A retired certificate and key may no longer be used for issuing 1894 new certificates, but is not considered revoked for the purpose of validation. 1895
An MCA or MICA certificate SHALL NOT be re-issued (e.g., re-signed with the same SubjectName 1896 and public key, but with a new validity period). Instead, if it is desired to retire an existing 1897 key/certificate, a new key pair SHALL be generated and bound into a new MCA or MICA certificate 1898 generally with a new serialNumber component of the SubjectName. Operationally, the responsible CA 1899 SHOULD verifiably1 destroy the private key of the retired certificate. Retired certificates MUST remain 1900 available to verify subsidiary certificates. A replacement of a MCA or MICA SHOULD use a new name 1901 formed by incrementing or otherwise adjusting the serialNumber component of the subject name. See 1902 Sections 8.11.8.2.1 and 8.11.8.2.2 for the format of the name. 1903
A side effect of the indefinite lifetime requirement coupled with the permanent embedding of the Device 1904 Certificate and its certificate chain within a device is that the device, MCA and MICA certificates 1905 MUST NOT and cannot be revoked once issued. Specifically, no MCA, MICA or SERCA shall issue or 1906 be required to issue CRLs and no MCA or MICA shall operate or have operated on their behalf any 1907 OCSP server for the purpose of providing validity information for any certificate under the 1908 Manufacturing PKI hierarchy. This does not preclude the use of a certificate and its corresponding 1909 identity to be used in a blacklist or whitelist for authorization purposes to allow or deny access to 1910 resources on a server. 1911
8.11.3.2 Device Certificate Lifetime 1912
[NIST SP800-57] treats the question of the expected lifetime of various algorithm choices and key 1913 lengths. For the purpose of this document, the Manufacturing PKI certificate uses a choice for algorithm 1914 and key length that currently have no end-use date. 1915
8.11.3.3 Device Certificate Validity 1916
A Device Certificate issued by the Manufacturing PKI is considered valid indefinitely. However, the 1917 validity of the certificate does not imply any authorizations for the holder of the certificate. Any relying 1918 party is responsible for maintaining a mechanism for determining whether a given certificate is usable 1919 (e.g., valid authenticator for specific resource, implicit authorization) in a given circumstance (e.g., an 1920 access control list or other white or black list). 1921
8.11.4 General Certificate Format 1922
8.11.4.1 RFC 5280 Compliance 1923
All certificates in the Manufacturing PKI SHALL be compliant with [RFC 5280]. 1924
8.11.4.2 IEEE 802.1AR Compliance 1925
Device Certificates and Device Test Certificates in the Manufacturing PKI SHALL be compliant with 1926 [IEEE 802.1AR] with the following exceptions: 1927
1 The process for destroying private keys is a business issue that should be covered by any contract for SERCA services.
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 61 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
� Device Certificates and Device Test Certificates take the general form of an iDevID certificate 1928 as defined in [IEEE 802.1AR]. 1929
� Differing from [IEEE 802.1AR] requirements, the SubjectName field of the Device Certificate 1930 is empty as the X500 name form is not well suited to describe or identify physical serialized 1931 devices2. The device identity is contained in the SubjectAlternativeName extension which 1932 contains a single GeneralName of type OtherName that is further sub-typed as a 1933 HardwareModuleName (id-on-HardwareModuleName) as defined in [RFC 4108]. Per 1934 [RFC 5280], this extension MUST be marked critical when the SubjectName field is empty. The 1935 hwType field of HardwareModule name is assigned by the SEP 2 manufacturer and SHOULD 1936 be different for each different type of manufactured device. 1937
8.11.5 General Restrictions and Conditions 1938
In addition, SEP 2 certificates have the following restrictions: 1939
� All SEP 2 certificates are X.509 v3 certificates as defined in [RFC 5280]. 1940
� The only permitted public key type for SEP 2 certificates in the Manufacturing PKI is an Elliptic 1941 Curve (EC) public key on the NIST P-256 curve. (Note: See Sections 8.11.8.3.3 and 8.11.8.3.4 1942 for details on the use of RSA Public Keys and certificates.) 1943
� The signature method for signatures formed by EC P-256 private keys MUST be SHA256 with 1944 ECDSA. 1945
� Within the Manufacturing PKI hierarchy, all certificates MUST contain only an EC P-256 1946 public key. That public key MUST contain an elliptic curve point in uncompressed form. See 1947 [RFC 5480] Section 2.2 for details on the uncompressed form. 1948
� Per [RFC 5280], CAs MUST ensure the uniqueness of the serial numbers on the certificates 1949 they issue. CAs MAY use one of three mechanisms to meet this requirement: comparison 1950 against previously issued certificates, monotonically increasing serial numbers or random octet 1951 string. For the latter method, true random strings of 8 octets are sufficient for certificates issued 1952 by SERCAs or by MCAs, random strings of 10 octets are sufficient for certificates issued by 1953 MICAs that are planning to issue less than 50 million certificates, and 11 octets are sufficient for 1954 MICAs that are planning to issue less than 250 million certificates3. 1955
� Per [RFC 5280], the IssuerName of any certificate MUST be identical to the signer's 1956 SubjectName. 1957
� With the exception of Device Certificates and Device Test Certificates as described in Sections 1958 8.11.2.3 and 8.11.2.4, the SubjectName MUST be non-empty. 1959
8.11.6 Extensions 1960
� The certificatePolicy extension in any certificate consists of one or more PolicyInformation 1961 objects containing only the policyIdentifier field. The PolicyInformation object MUST NOT 1962 contain any policyQualifier fields. If present, the policyQualifier field SHOULD be ignored. 1963
2 Or rather there are too many different possible ways to represent these types of entities using X500 Distinguished Names. Rather than attempt to resolve the differences between each individual company’s interpretation of SubjectName guidance in [IEEE 802.1AR], we constrain the identity expression to just the SubjectAlternativeName format described in [IEEE 802.1AR]. 3 This is derived from the Birthday Collision problem where we want to set the chance of collision in the random space at less than 10^8. 8 octets ~= 600K certs, 10 octets ~= 155M certs, 11 octets ~= 2.5B certs signed without serial number collision.
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 62 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
� In the Manufacturing PKI hierarchy, each Device Certificate and the CAs that make up the 1964 Device Certificate's path contain one or more device type identifiers encoded in the 1965 certificatePolicy extension in the PolicyInformation: policyIdentifier field. These 1966 policyIdentifier Object Identifier (OID)s [RFC 5280] are taken from those OIDs defined under 1967 the deviceType arc of the [CSEP] OID tree. See Section 8.11.7.1 below for acceptable values 1968 and for information on the management of that arc. 1969
� Each certificate in the Manufacturing PKI hierarchy MUST have a Valid: notBefore field 1970 consisting of the time of issue encoded as per [RFC 5280] Section 4.1.2.5 and a Valid:notAfter 1971 field consisting of the GeneralizedTime value 99991231235959Z (see [RFC 5280], Section 1972 4.1.2.5) for 256-bit ECC-based certificates. 1973
� Each CA certificate MUST contain a SubjectKeyIdentifier extension with an 8-octet key 1974 identifier generated as per method (2) of Section 4.2.1.2 of [RFC 5280]. A non-CA certificate 1975 MAY contain a SubjectKeyIdentifier extension – if it does, such extension MUST be generated 1976 as per method 2 of Section 4.2.1.2 of [RFC 5280]. In both cases, the extension MUST be 1977 marked non-critical. 1978
� SEP 2 devices MUST be able to follow a chain where the key identifier was not generated in 1979 compliance with this section but where there is correspondence in actual values between a child 1980 AuthorityKeyIdentifier and a parent's (CA's) SubjectKeyIdentifier. 1981
� Each certificate, except self-signed client certificates and root certificates, MUST contain an 1982 AuthorityKeyIdentifier extension of form [0] KeyIdentifier where the value of the KeyIdentifier 1983 field is taken from the value of the SubjectKeyIdentifier extension of the certificate issuer. The 1984 extension MUST be marked non-critical. 1985
8.11.7 Additional ASN1 Definitions 1986
The [CSEP] object identifier arc has been allocated by the IANA as follows: 1987
csep OBJECT IDENTIFIER ::= { iso(1) identified-organizations(3) dod(6) internet(1) private(4) 1988 enterprise(1) 40732 } 1989
8.11.7.1 SEP 2 Device Type Assignments 1990
The deviceType is included in the CertificatePolicy extension of the Device Certificate and its issuing 1991 chain of CA certificates. It may be used for authorization purposes as described in Section 8.2.2.3.3. 1992
deviceType OBJECT IDENTIFER ::= { csep 1} 1993
id-SEP 2-dev-genericSEP 2Device OBJECT IDENTIFIER ::= { deviceType 1 } 1994 -- used for most devices 1995
id-SEP 2-dev-mobile OBJECT IDENTIFIER ::= { deviceType 2 } 1996 -- used in addition to genericSEP 2Device to identify "mobile" SEP 2 1997 -- entities (may be homed to multiple ESI domains) 1998
id-SEP 2-dev-postManufactureSEP 2 OBJECT IDENTIFIER ::= { deviceType 3 } 1999 -- used in device certs issued post-manufacture 2000
8.11.7.2 SEP 2 Policy Assignments 2001
One or more of SEP 2Policy OIDS MAY be included in the Device Certificate and its issuing chain of 2002 CA certificates. 2003
SEP 2 Policy OBJECT IDENTIFIER ::== { csep 2 } 2004
id-SEP 2-po-device-auth-test OBJECT IDENTIFIER ::= { SEP 2 Policy 1 } 2005 -- MUST be included in test certificates 2006
id-SEP 2-po-selfsigned-client OBJECT IDENTIFIER ::= { SEP 2 Policy 2 } 2007 -- MUST be included in SEP 2 self-signed certificates 2008
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 63 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
id-SEP 2-po-service-provider OBJECT IDENTIFIER ::= { SEP 2 Policy 3 } 2009 -- MUST be included in commercial certificates issued to 2010 -- service providers for SEP 2 purposes. 2011
Id-SEP 2-po-bulk-cert OBJECT IDENTIFIER ::= { SEP 2 Policy 4 } 2012 -- MUST be included in bulk-issued certificates (e.g., 2013 -- where the private key is generated off the device by the 2014 -- issuing CA 2015
8.11.7.3 HardwareModuleName 2016
Excerpted from [RFC 4108]: 2017
id-on-hardwareModuleName OBJECT IDENTIFIER ::= { 2018 iso (1) identified-organizations(3) dod(6) 2019 internet(1) security(5) mechanisms(5) pkix(7) on(8) 4 } 2020
HardwareModuleName ::= SEQUENCE { 2021 hwType OBJECT IDENTIFIER, 2022 hwSerialNum OCTET STRING } 2023
The hwType field is assigned from the manufacturer's own OID arc according to its own policies. The 2024 OID MUST be unique for each different manufacturer's device model and / or type. The manufacturer's 2025 device type is NOT the same as the SEP 2 device type OID; instead it represents a single specific 2026 product from a specific manufacturer. 2027
The hwSerialNum field is an unstructured field that the manufacturer should assign according to its own 2028 policies and SHOULD be related to the serial number or other identifier on the device's external 2029 physical label. 2030
The combination of hwType and hwSerialNum MUST be unique. 2031
Example: 2032
vendor1Devices OBJECT IDENTIFIER ::= { vendor1 13 } 2033
meterNicV1 OBJECT IDENTIFIER ::= { vendor1Devices 1 1 } 2034 2035
HardwareModuleName = { 2036 OID:1.3.6.1.4.1.99999.13.1.1, -- Vendor1 MeterNic V1 2037 OCTET STRING: 0x0a43218800 } -- Serial Number 44075-943936 2038
8.11.8 Certificate Profiles 2039
The certificates listed here have the normal [RFC 5280] format and the descriptions for all the fields 2040 listed in the subsequent sections are described in [RFC 5280]. The absence of a field in the certificate 2041 description is simply for conciseness and does not imply its absence in the certificate. In particular, the 2042 Issuer Name is omitted in most of the certificate descriptions as [RFC 5280] requires it to be identical to 2043 the Subject Name of the issuing certificate. 2044
By specification, [RFC 5280] certificates are encoded using the ASN1 Distinguished Encoding Rules. 2045 For management or transmission purposes, they MAY be sent as ASN1 Distinguished Encoding Rules 2046 (a file or stream of octets) or BASE64 encoded and possibly armored (i.e., "Privacy-Enhanced Mail 2047 (PEM) format"). 2048
SEP 2 devices MUST accept unexpected (not listed in this profile) certificate extensions and MUST 2049 silently ignore non-critical unrecognized certificate extensions. Per [RFC 5280], devices MUST reject 2050 any certificate containing unrecognized critical certificate extensions. 2051
8.11.8.1 Root Certificate 2052
A SERCA instance (e.g., contracted for CA operation) SHALL have exactly one self-signed certificate. 2053 There MAY be more than one SERCA instance. 2054
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 64 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
The SERCA certificates are the root of trust for the Manufacturing PKI. They MUST contain the 2055 extensions described below and MUST have the name form as described. They SHOULD NOT contain 2056 any additional extensions. 2057
� Issued by: Self-signed 2058
� Issuer Name: O=Smart Energy, CN=SEP 2 Root, serialNumber=<n> 2059
� Subject Name: O=Smart Energy, CN=SEP 2 Root, serialNumber=<n> 2060
� Extensions 2061 o certificatePolicy: critical; 1:anyPolicy 2062 o keyUsage: critical; keyCertSign, crlSign 2063 o basicConstraints: critical; cA=true, pathLen absent (unlimited) 2064 o subjectKeyIdentifer: Section 8.11.6 2065
Note: The root certificate is primarily a container for a Trust Anchor. 2066
8.11.8.2 Manufacturing Hierarchy Certificates 2067
8.11.8.2.1 MCA Certificate 2068
MCA certificates MUST contain the extensions described below and MUST have at least the O and CN 2069 components of the Subject Name as described. They SHOULD comply with the name form as described 2070 below. They SHOULD NOT contain any additional extensions. 2071
� Issued by: SERCA 2072
� Subject Name: C=<country>, O=<Manufacturing Org>, CN=SEP 2 MCA, 2073 serialNumber=<num> 2074
� Extensions: 2075 o certificatePolicy: critical; at least one SEP 2 device type Identifier OID as a 2076
policyIdentifier 2077 o keyUsage: critical; keyCertSign 2078 o basicConstraints: critical; cA=true, pathLen=1 2079 o subjectKeyIdentifier: Section 8.11.6 2080 o authorityKeyIdentifier: Section 8.11.6 2081
8.11.8.2.2 MICA Certificate 2082
MICA certificates MUST contain the extensions described below and MUST have at least the O and CN 2083 component of the Subject Name as described. They SHOULD comply with the name form as described 2084 below. They SHOULD NOT contain any additional extensions. 2085
� Issued by: SERCA or MCA 2086
� Subject Name: C=<country>, O=<Manufacturing Org>, CN=SEP 2 MICA, 2087 serialNumber=<num> 2088
� Extensions: 2089 o certificatePolicy: critical; at least one SEP 2 device type Identifier OID as a 2090
policyIdentifier 2091 o keyUsage: critical; keyCertSign 2092 o basicConstraints: critical; cA=true, pathLen=0 2093 o subjectKeyIdentifier: Section 8.11.6 2094 o authorityKeyIdentifier: Section 8.11.6 2095
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 65 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
8.11.8.2.3 Device Certificate 2096
Device Certificates MUST contain the extensions described below. The Subject Name field MUST be 2097 empty. They SHOULD NOT contain any additional extensions. Except as modified by Section 8.11.4, 2098 the certificate is compliant with [IEEE 802.1AR]. 2099
The device type identifier OID(s) MUST be selected from those present in the issuing certificate's 2100 certificatePolicy extension. 2101
� Issued by: SERCA or MICA 2102
� Subject Name: [EMPTY] 2103
� Extensions: 2104 o certificatePolicy: critical; generally exactly one SEP 2 device type identifier OID as a 2105
policyIdentifier. 2106 o subjectAlternativeName: critical; one GeneralName of type OtherName of 2107
hardwareModuleName (see Section 8.11.7.3 above for specific field values). 2108 o keyUsage: critical; one or more of keyAgreement, digitalSignature. 2109 o authorityKeyIdentifier: See Section 8.11.6. 2110
8.11.8.2.4 Device Test Certificate 2111
Device Test Certificates MUST contain the extensions described below. The Subject Name field MUST 2112 be empty. They SHOULD NOT contain any additional extensions. Except as modified by Section 2113 8.11.4, the certificate is compliant with [IEEE 802.1AR]. 2114
The device type identifier OID(s) MUST be selected from those present in the issuing certificate's 2115 certificatePolicy extension. 2116
Note: This is the same format as the Device Certificate with the exception of an additional id-SEP 2-po-2117 device-auth-test as policyIdentifier in the certificatePolicy extension. 2118
8.11.8.3 Other Certificates 2119
There are a few other certificates that a SEP 2 device may see. 2120
8.11.8.3.1 Additional Certificates for SEP 2 Native Devices 2121
8.11.8.3.1.1 General Considerations 2122
In addition to the certificates described in Section 8.11.8.2.3 above, native devices MAY include 2123 certificates (and their related key pairs) issued outside of the Manufacturing PKI. The provision of such 2124 certificates and support for them is OPTIONAL. 2125
A manufacturer MAY contract with any reputable Certificate Authority for the issuance of non-SEP 2 2126 Manufacturing certificates incorporating RSA public keys. The purpose for doing so is to provide 2127 backwards-compatible support to client devices, software and systems that may not yet support Elliptic 2128 Curve. 2129
Non-SEP 2 certificates MAY be placed in the device at one of two times: 2130
� During manufacture, either as a complete credential incorporating both private key and 2131 certificate, or as a certificate issued for a public key generated by the device. 2132
� During customer install as an over-the-net installation assuming connection to the Internet. 2133
For the latter approach, the specific protocol used to install the certificate is vendor-dependent and 2134 should assume only normal Internet connectivity. Specifically, it should not depend on any "proxy" or 2135 third-party assistance within the customer's home or the service provider's back-office. 2136
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 66 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
8.11.8.3.1.2 Certificate Structure and Certificate Chain Considerations 2137
The certificate installation for these additional certificates MUST include the complete chain of 2138 certificates needed to validate the certificate, including the root of trust certificate for the chain. 2139
The certificates MUST contain an RSA 2048-bit public key, and MUST be signed using SHA256 with 2140 RSA. They SHOULD contain an expiration data not later than December 31st, 2028. As the provision of 2141 RSA certificates is considered a transition mechanism, this is an appropriate way to phase out the use of 2142 such certificates and the RSA signature algorithms. Intermediate certificates in the chain SHOULD 2143 contain an expiration date not earlier than December 31st, 2020. 2144
The SEP 2 device SHOULD permanently stop using the certificate and related private key upon 2145 certificate or chain expiration if the device has a mechanism for determining time and date. 2146
The Subject Name form for the Device Certificate MAY be any form approved by the certificate issuer. 2147 This specification recommends that the Subject Name be crafted as: "C=<Country of 2148 certification>,O=<Manufacturer>, OU=<Device type>, UID=<Serial Number>". An RSA certificate 2149 MUST NOT use a SubjectAlternativeName extension in place of a SubjectName unless it is identical to 2150 the SubjectAlternativeName extension in the device's Device Certificate. 2151
8.11.8.3.1.3 Use Case 2152
The above-described certificates are targeted for use when an external client connects to a server using 2153 TLS. The TLS negotiation and response is thus: 2154
� When a SEP 2 device containing an additional RSA certificate receives a TLS Client Hello 2155 containing only a supported RSA cipher suite, it SHOULD answer any certificate negotiation 2156 with the non-SEP 2 RSA certificate. 2157
� If a SEP 2 device receives a TLS Client Hello containing both EC and RSA supported cipher 2158 suites, it SHOULD respond using its EC Device Certificate, regardless of cipher suite 2159 preference order. 2160
� If a SEP 2 device without an additional certificate receives a TLS Client Hello containing only 2161 an RSA cipher suites, it MUST reject the connection with the appropriate code. 2162
8.11.8.3.2 Self-Signed Client Certificate 2163
Any application designed to talk to native SEP 2 products or applications implementing SEP 2 functions 2164 may create a credential for itself consisting of a self-signed [RFC 5280] certificate. The application 2165 generates the key pair and binds the public key in a certificate. The credential privilege is installed in the 2166 SEP 2 device by either passing the certificate or a fingerprint of the certificate along with the credential 2167 privileges to the appropriate SEP 2 application using an enrolment protocol (not specified here) or other 2168 mechanism (e.g., web portal mechanism for moving from unsecure to secure). 2169
A SEP 2 device or application acting in a client role SHALL reject a self-signed certificate if presented 2170 by the server. A SEP 2 device or application acting in a server role MAY legitimately receive a Self-2171 signed Certificate from a potential client. The server SHALL verify that the Self-signed Certificate 2172 follows the format described below and SHALL reject the certificate if there are any discrepancies. A 2173 server MUST NOT treat a Self-signed Certificate received through a TLS Handshake as corresponding 2174 to a root CA, unless the public key carried in the Self-signed Certificate is the same as one of the pre-2175 provisioned roots. 2176
� Issued by: Self-signed 2177
� Subject Name: Any – suggested: O=<application name>,CN=<12digit random hex string> 2178
� Issuer Name: Identical to Subject Name 2179
� Validity: notBefore: time of issue; notAfter: maximum of time of issue plus 3 years. 2180
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 67 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
� Subject Public Key and Signature: SHOULD be EC P-256 and SHA256withECDSA, MAY be 2181 RSA 2048 and SHA256withRSA. 2182
� Extensions 2183 o keyUsage: critical; at least digitalSignature, others as appropriate. 2184 o certificatePolicy: critical; at least one policyIdentifier:id-SEP 2-po-selfsigned-client. 2185
8.11.8.3.3 Generic Client Certificates for non-SEP 2 Entities 2186
In addition to application issued self-signed certificates, an application may use a certificate issued by a 2187 global or local CA as an application credential for use with the SEP 2 protocol. As with a self-signed 2188 certificate, the credential privilege is installed in the SEP 2 device or application by either passing the 2189 certificate or a fingerprint of the certificate along with the credential privileges. At a later date, SEP 2 2190 may specify further uses for certificates not issued under the SEP 2 certificate hierarchies. 2191
There are no differences between the uses for a self-signed client certificate and "other" client 2192 certificates. The major difference is simply how the certificates are issued or who issues them. One 2193 example of an "other" client certificate would be an email or SSL client certificate issued by one of the 2194 well-known Certificate Authorities. 2195
Client certificates by the SEP 2 definition are those that do not contain a basicConstraints extension. 2196
8.11.8.3.4 Generic Server Certificates for non-SEP 2 Entities 2197
SEP 2 devices or applications may need to connect to TLS servers secured by server certificates issued 2198 by global or local CAs not affiliated with [CSEP]. For interoperability with this profile, those certificates 2199 MUST meet the following requirements: 2200
� MUST contain either an RSA 2048-bit public key or a EC P-256 public key. 2201
� MUST be signed either using either the SHA256withRSA or SHA256withECDSA algorithms. 2202
In addition, the SEP 2 client device MUST have a valid root of trust for the server certificate. This can 2203 be installed at manufacture, or installed by the operator or owner after the device is operational. The 2204 methods for the installation of these additional roots of trust are vendor specific. 2205
The connectivity of SEP 2 devices to external devices is subject to further specification. 2206
8.11.9 Device Requirements 2207
8.11.9.1 Private-key Protection 2208
Device manufacturers SHOULD ensure that, once installed, private keys cannot be exported from the 2209 device. 2210
8.11.9.2 Trusted Key Store Protection 2211
Device manufacturers SHALL ensure that the current active Smart Energy Root CA (SERCA) 2212 certificates or root public keys are embedded in the device at the time of manufacture and firmware 2213 upgrade. They SHALL ensure that, once installed, the Root CA public keys cannot be overwritten via an 2214 over-the-air action, except as a by-product of a successful firmware upgrade. 2215
8.11.9.3 Certificate Usage 2216
Device manufacturers SHALL ensure that a complete and valid Manufacturing PKI certificate chain 2217 (e.g., SERCA, MCA if any, issuing MICA if any, and Device Certificate) is embedded in the device at 2218 the time of manufacture. 2219
In an authentication exchange, the device SHALL supply a complete and valid chain comprising its own 2220 certificate and any intermediate CA certificate between the device and the root (i.e.; all certificates in its 2221 chain except its SERCA). 2222
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 68 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
8.11.9.4 Trusted Certificate Store 2223
A device meant to act as a server to non-SEP 2 entities MUST incorporate at manufacture a list of 2224 certificates for non-SEP 2 Root CAs recommended by [CSEP] for use as TLS trust anchors. These non-2225 SEP 2 Root CAs typically have no association with [CSEP] or a SERCA. 2226
The [CSEP] shall publish such a list of certificates on its website and shall update the list no less often 2227 than annually. Manufacturers are responsible for ensuring the update of their manufacturing processes 2228 within 60 days of the publication of a new list. There shall be an initial list size of 10 non-SEP 2 Root 2229 CA certificates, increasing by one a year to a maximum of 20 non-SEP 2 Root CA certificates. 2230
Vendors SHOULD incorporate an update of the trust store as part of any firmware update where 2231 appropriate. Vendors MAY provide a mechanism for a consumer / customer to set the trust status of any 2232 Root CA certificate and to add and delete such certificates from the trust store of their owned device. 2233
8.11.10 Certificate Verification 2234
SEP 2 devices and applications MUST follow the procedure defined in [RFC 5280], Section 6 to verify 2235 certificates. 2236
Certificate verifiers MUST reject certificates that contain one or more unsupported critical extensions. 2237
Policy-mapping is not supported, and certificates containing policy mappings MUST be rejected. 2238
Policy-qualifiers are not supported. Therefore, issuers SHOULD NOT include policy qualifiers in 2239 certificates. However, verifiers SHOULD NOT reject certificates containing policy qualifiers unless 2240 there are other reasons to do so. 2241
Name-constraints are not supported and certificates containing name-constraints MUST be rejected. 2242
Any extension not listed by name within this document SHOULD NOT be included within a compliant 2243 certificate and, if included, MUST NOT be marked critical. 2244
8.11.10.1 Additional Considerations for Serving SEP 2 to Non-native Entities 2245
A SEP 2 device MAY implement OCSP for the sole purpose of validating non-SEP 2 certificates (e.g., 2246 as received from clients and applications using generic or self-signed client certificates, or when 2247 contacting generic servers). In addition or in lieu of this, a SEP 2 device or application may use a white 2248 list or other access control list to determine acceptance of an offered client certificate from an external 2249 source. A SEP 2 device or application MUST NOT use OCSP for the purpose of attempting to validate 2250 Manufacturing PKI-issued certificates. 2251
As none of the Manufacturing PKI CAs issue either CRLs or run OCSP servers, no non-SEP 2 device or 2252 application may use CRLs or OCSP for the purpose of attempting to validate SEP 2 certificates. 2253
8.11.11 Certificate Related Labeling Requirements 2254
For the purposes of Access Control Lists and other human-readable actions, the device will be identified 2255 by the data listed in Section 8.3. These data may be used as appropriate to label a device or its 2256 packaging. 2257
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 69 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
9 Discovery 2258
Smart Energy Profile 2.0 specifies DNS-based methods for service discovery, resource discovery, and 2259 hostname to IP address resolution. A service is defined as an application instance uniquely identified by 2260 {host, port, protocol}, where protocol in this case is SEP 2 plus its underlying transport bindings (e.g., 2261 HTTP(S)/TCP/IP). DNS-based Service Discovery (DNS-SD) [RFC 6763] is a conventional use of 2262 existing DNS name syntax and message and record formats (PTR, SRV, TXT) to discover instances of a 2263 given service within a given domain. In SEP 2.0, DNS-SD [RFC 6763] is used to describe the location 2264 of function sets and groups of resources by supplying the host, port and protocol of the supporting 2265 servers along with additional details provided by those servers. 2266
DNS-SD specifies that a DNS SRV and TXT record pair are used to describe a service instance. Both 2267 records have an identical Service Instance Name of the form "<Instance>.<Service>.<Domain>". The 2268 SRV record contains the hostname and port of the service, while the TXT record may contain additional 2269 variables (such as a relative path) in text form. A service plus a path forms a URI and can be used to 2270 locate a resource. A client discovers instances of a given service or resource type by sending a query for 2271 a DNS PTR record with the name "<Service>.<Domain>", which returns a set of zero or more Service 2272 Instance Names of DNS SRV/TXT record pairs for the requested service or resource type. 2273
Multicast DNS (mDNS) [RFC 6762] provides the ability to perform DNS-like queries on the local link 2274 in the absence of any conventional unicast DNS server. In addition, mDNS reserves the top-level DNS 2275 domain ".local." to name services that have link-local scope. mDNS employs link-local multicast 2276 addressing for requests and either multicast or unicast addressing for responses in support of service 2277 discovery. IPv6 address scoping is used to specify reachability and includes address types for global, 2278 site-local, and link-local addressing [RFC 4291]. 2279
Extended Multicast DNS (xmDNS) [I-D XMDNS] extends the scope of mDNS beyond the local link 2280 through the use of site-local multicast requests and responses. In addition, xmDNS reserves the top-level 2281 DNS domain ".site." to name services that have site-local scope. The site-local multicast address 2282 FF05::FB is designated for Extended Multicast DNS and SHALL be used as the destination address for 2283 all xmDNS multicast requests and multicast responses. The reachability of this address is 2284 administratively defined and MAY span multiple sub-networks. SEP 2 SHALL use global addresses or 2285 Unique Local Addresses [RFC 4193] in the source address of xmDNS requests and responses. xmDNS 2286 [I-D XMDNS] is normative for SEP 2. 2287
Guidelines on the use of unicast responses SHALL be employed as described in the xmDNS draft unless 2288 noted otherwise. xmDNS requests from HAN devices that are mains powered SHALL use site-local 2289 multicast addressing to ensure that all sub-networks within the HAN are reachable and MAY request 2290 unicast responses. Battery operated devices in the HAN SHOULD use site-local multicast addressing for 2291 xmDNS requests and SHOULD request unicast responses. HAN devices making xmDNS requests that 2292 generate responses specific to the requesting HAN device (e.g., requests such as those requesting 2293 EndDevice servers where the particular HAN device is registered) SHALL employ site-local multicast 2294 destination addresses and SHALL request unicast responses. When a server receives a request with the 2295 QU bit set it SHALL return a unicast response. 2296
9.1 Service Instance 2297
A server SHALL assign a unique <Instance> label of up to 63-bytes in UTF-8 format for each DNS 2298 SRV / TXT record pair that it advertises. In order to avoid name conflicts, <Instance> names SHOULD 2299 begin with a meaningful substring followed by a hyphen '-' and end with the device's SFDI or other 2300 collision-resistant substring such as the low-order bits of an EUI-64 in text form (e.g., device-2301 000001111114). Should a name conflict occur, a device SHALL assign itself a new name until conflicts 2302
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 70 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
are resolved. A conflict SHOULD be resolved by appending a decimal integer in parentheses to the 2303 <Instance> (for example, Name(2)for the first conflict, Name(3)for the second conflict, etc.). 2304
If a DNS SRV/TXT record pair is created to advertise a function set, its <Instance> SHOULD consist of 2305 the corresponding string from the Subtype column of Table 9-2 followed by a hyphen and a collision-2306 resistant substring as defined above (e.g., upt-000001111114). When an SFDI is used as part of a DNS-2307 SD label, it SHALL be represented as 12 decimal digits including leading zeros (if any) as well as the 2308 checksum digit and SHALL NOT include embedded hyphens. 2309
9.2 Service Name 2310
The Service Name used with SEP 2 DNS-SD SHALL be smartenergy and has been registered 2311 appropriately with IANA [IANA SN]. 2312
The <Service> portion of a Service Instance Name consists of the Service Name preceded by an 2313 underscore _ and followed by a period plus a second DNS label specified by SEP 2 as _tcp. 2314
Thus, a valid Service Instance Name example would be: 2315
device-000001111114._smartenergy._tcp.site. 2316
Where device-000001111114 is the <Instance> portion (described above), smartenergy is the Service 2317 Name, tcp is the transport protocol, and "site." is the <Domain> portion (xmDNS is being utilized in 2318 this example). 2319
9.3 TXT Record 2320
This sub-section specifies the format of the TXT record to be used in conjunction with SEP 2 DNS-SD. 2321 The Smart Energy Profile 2.0 application SHALL use a single TXT record format. The following table 2322 describes the supported TXT record parameters for Smart Energy Profile 2.0. 2323
Table 9-1 TXT record parameters. 2324
Key=Value Example
txtvers={#} txtvers=1
dcap={relative reference to DeviceCapabilities} dcap=/dcap
path={relative reference to the function set} corresponding to the specified subtype name
path=/upt
https={port } https=443
level={schema extensibility level indicator} level=-S0
txtvers SHALL be the first key in the TXT record. For version 2.0 of the Smart Energy Profile, the 2325 value of the txtvers key SHALL be 1. If it is found in a response to be other than 1, the TXT record 2326 SHALL be ignored. 2327
The txtvers key SHALL be present with a non-empty value. Clients SHALL silently discard TXT 2328 records with txtvers keys that are not present with a non-empty value of 1. 2329
Unknown key=value pairs in a response SHALL be ignored. 2330
The dcap key SHALL provide the relative reference used to locate the device's DeviceCapability 2331 resource and SHALL include the leading slash of the given path. 2332
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 71 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
The dcap key SHALL be present with a non-empty value. Clients SHALL silently discard TXT records 2333 with dcap keys that are not present with a non-empty value representing the URI for the server's 2334 DeviceCapability resource. 2335
The path key is used in responses to subtype queries (see below) and SHALL provide the relative 2336 reference used to locate the base path of a specified function set or resource, including the leading slash 2337 '/' of the given path. 2338
The path key SHALL be omitted in response to service name queries. The path key SHALL be present 2339 with a non-empty value representing the URI satisfying the subtype query. Clients SHALL ignore path 2340 keys included with service name query responses where the path key is supplied with no value or 2341 present with an empty value. 2342
The https key is used to indicate whether or not the function set requires a secure (HTTP over TLS) 2343 connection. If a value is present for this key in the TXT record, a client SHOULD locate the 2344 corresponding function set or resource using a secure connection to the specified port in order to avoid a 2345 re-direct. 2346
The https key MAY be present with no value or present with an empty value if HTTPS is supported for 2347 the query using the default port of 443. Servers supporting HTTPS using a non-default port SHALL 2348 indicate the port number by including the https key with a non-empty value representing the supported 2349 HTTPS port number. Clients SHALL use HTTP for the service if the https key is not present. Clients 2350 SHALL use HTTPS using the default port for the service if the https key is present with no value or 2351 present with an empty value. Clients SHALL use HTTPS using the port number indicated if the https 2352 key is present with a non-empty value. 2353
The level key is used to indicate the Extensibility Level of the schema for the specified function set (see 2354 Section 7.7). The default value SHALL be the supported Extensibility Level of the server. If “-S[i]” is 2355 provided in the level key, the server does not support extensions to the schema. If “+S[i]” is provided 2356 in the level key, the server SHALL support either of “-S[i]” or “+S[i]” as negotiated through the HTTP 2357 Accept header. 2358
The level key SHALL be present with a non-empty value. Clients SHALL silently discard TXT records 2359 with level keys that are not present with a non-empty value representing the servers schema level 2360 extensibility indicator. 2361
9.4 Subtype Queries 2362
Subtype names act as filters that return the SRV / TXT record pairs describing a given function set. For 2363 example, if a device such as an electricity meter also serves gas metering data via mirroring, that device 2364 will register two subtype names; one for providing metering data and one for the capability to receive 2365 metering data to mirror. A client device can search for instances of a given function set by first 2366 performing a subtype query and then interrogating the Device Capabilities URIs (contained in the 2367 returned TXT records) to determine the URIs for that function set. Alternately, it may use a path 2368 returned directly by the server as described below. 2369
SEP 2 uses an extended form of subtype query in order to support fine-grained resource discovery and 2370 conserve bandwidth. Using this method, a server will return a separate SRV / TXT record pair for each 2371 function set that it supports. The name of the DNS-SD PTR record is equivalent to the query argument 2372 and the value of the PTR record is the Service Instance Name of an SRV / TXT record pair matching the 2373 query. 2374
A server SHALL register a PTR record with a subtype name as defined below for each function set that 2375 it advertises for discovery. In addition, the server SHALL register a unique SRV / TXT record pair with 2376
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 72 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
an <Instance> as defined in Section 9.1 for each function set that is referenced by the subtype PTR 2377 record. 2378
All SRV records registered on a given device SHALL contain identical values. The port value contained 2379 in the SRV record SHALL be specified for the default (http) scheme. If a secure connection is required 2380 for the function set or resource, then the https key SHALL be present in the TXT record as specified in 2381 Section 9.3. 2382
The server SHALL register exactly one PTR record with the name "_smartenergy._tcp.site.". The SRV 2383 / TXT record pair referenced by this PTR record refers to the server itself. Enumerating the set of all 2384 SEP 2 servers in the HAN is STRONGLY DISCOURAGED except for diagnostic purposes. Instead, 2385 devices SHOULD use subtype queries as described in this section to enumerate SEP 2 function sets. 2386
The TXT record of the SRV / TXT record pair referenced by a subtype PTR record SHALL conform to 2387 the definition given in Section 9.3 and SHALL contain the relative reference for the base path of the 2388 function set that corresponds to the specified subtype. The key=value pairs other than path and https 2389 SHOULD be identical for all TXT records registered on a single device. 2390
Subtype names are comprised of a subtype string, followed by "_sub._smartenergy._tcp.site.". 2391 Subtype strings SHALL NOT begin with an underscore (see Table 9-2). For example, the subtype name 2392 for the meter usage point function set shall be composed as "upt._sub._smartenergy._tcp.site.". Other 2393 subtype names SHALL (except as noted below) be composed per the meter usage point example. 2394
The following table lists the defined service subtype strings and their corresponding SEP 2 function sets. 2395
Table 9-2 Service subtype strings and their corresponding SEP 2 function sets. 2396
Subtype Device Capabilities Field Name SEP 2 Function Set
bill CustomerAccountLink Billing
derp DERProgramLink Distributed Energy Resources
dr DemandResponseProgramLink Demand Response / Load Control
edev EndDeviceLink End Device
file FileLink File Download
msg MessagingProgramLink Messaging
mup MirrorUsagePointLink Metering Mirroring
ppy PrepaymentLink Prepayment
rsps ResponseSetLink Response
sdev SelfDeviceLink Self Device
tm TimeLink Time
tp TariffProfileLink Pricing
upt UsagePointLink Metering
To promote search efficiency, servers that support the End Device function set SHALL register a unique 2397 PTR, SRV, and TXT record for each remote device that they support. In this case, the subtype name 2398 SHALL consist of the string edev, concatenated with a hyphen and the remote device's SFDI, (see 2399 Section 8.3.2) and followed by "_sub._smartenergy._tcp.site.". For example, a server having an End 2400 Device resource for the remote device with SFDI 222222222228 would register a subtype PTR record 2401 named "edev-222222222228._sub._smartenergy._tcp.site.". 2402
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 73 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
The <Instance> portion of the Service Instance Name of the associated SRV / TXT record pair for this 2403 subtype PTR SHOULD consist of three parts, concatenated by hyphens. The first part SHALL consist 2404 of an identifier unique across End Device instances on this server. The second part SHALL be the edev 2405 subtype string. The third part SHOULD be the server's SFDI. For example, a server having the SFDI 2406 "000001111114" would register SRV and TXT records having the Service Instance Name "127-edev-2407 000001111114._smartenergy._tcp.site.", where 127 is an arbitrary decimal number unique to this 2408 specific End Device instance on this server. This name would be referenced by the subtype PTR record 2409 described in the example above. The TXT record with this name would contain the path to the End 2410 Device resource of the remote device. 2411
9.5 Discovery Procedure 2412
This section provides a walkthrough of the process a client would use to find a resource of interest using 2413 the appropriate portions of this specification. 2414
Link-layer joining is not covered in this specification. Refer to the appropriate specification for details 2415 regarding joining the appropriate data link-layer network. 2416
The following sequence demonstrates the discovery process using DeviceCapabiltities (as opposed to 2417 Function Set Assignments). This sequence assumes some knowledge either from other specifications or 2418 from other sections in this document, therefore these may need to be read before this sequence is fully 2419 understood. 2420
1) Use xmDNS/DNS-SD to locate the servers with the function sets of interest 2421 (See [I-D XMDNS], [RFC 6763]). 2422
2) For each server do the following: 2423
a) Establish TLS session if required (see Section 8). 2424
b) GET the Device Capabilities resource (See Section 10.2). 2425
c) Look for the desired function set in the Device Capabilities resource. 2426
d) If there is an entry in Device Capabilities it will contain a URI of the entry point for that 2427 function set. 2428
e) Alternately, use the path returned in the subtype query response (See Section 9.4). 2429
3) Determine which of the discovered resources are of interest. This depends on the resource and 2430 other outside factors (e.g., if the resource is "metering", then the meter of interest might be the 2431 one that has the Premises Aggregation Point attribute set to true). 2432
It should be noted that clients SHALL dynamically discover the URI(s) of the resource(s) of interest, as 2433 the URI(s) MAY vary from server to server and MAY occasionally vary over the lifetime of a given 2434 server. Clients SHALL rediscover URIs upon notification of the server DNS-SD record change or a 2435 request fails with a 404 (Not Found) error. Clients SHALL in the case of redirects, follow the guidance 2436 in the HTTP specification [RFC 2616]. 2437
2438
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 74 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
10 Support Resources 2439
This section defines resources and function sets that provide operational information to the end devices 2440 of an SEP 2 network or provide those end devices with services to manage and support their operation. 2441 The section begins with a general description of how each of sub-sections of this and the following two 2442 sections are organized. 2443
10.1 Resource Section Outlines 2444
This section gives the reader a basic understanding of the outline of each of the sections describing the 2445 resources of SEP 2. The intent is that each of these resources can be implemented on independent 2446 servers or grouped to coexist on a single server. Keep in mind that these resources or Function Sets are 2447 defined in three documents, the SEP 2 Application Specification (this document), the SEP 2 XML 2448 Schema and the SEP 2 WADL described in document [ZB 13-0201]. All three need to be consulted to 2449 get a full understanding of SEP 2. 2450
The Resource sections follow a standard "template", sometimes modified based on unique 2451 circumstances. Each section is outlined as follows: 2452
1) Overview 2453
2) List Ordering 2454
3) Application Guidelines / Behavior 2455
4) LogEvents 2456
Each of these sections is discussed in more detail below. 2457
10.1.1 Overview 2458
Contains a brief, three-to-four sentence, informative description of the functionality provided by the 2459 function set or resource. It does not state normative requirements. 2460
10.1.2 List Ordering 2461
This section provides guidance regarding: how resource elements and attributes are used to support 2462 unique ordering of resources within lists. 2463
Table 10-1 Function Set List Ordering. 2464
Resource Name Primary Key Secondary Key Tertiary Key
Resource Resource.elementA (descending or ascending)
Resource.elementC (descending or ascending)
NA
Sub-Resource Sub-Resource.elementD (descending or ascending)
Sub-Resource.elementB (descending or ascending)
NA
10.1.3 Application Guidelines / Behavior 2465
This section describes the normative, high level behavior of the function set and defines how the 2466 function set resources are used by clients and servers to accomplish the goals of the function set. 2467 Normative definitions of resource elements and attributes can be found in the XML schema described in 2468 [ZB 13-0201]. This section contains non-trivial information about resources that is too complex to be 2469 represented in the XML schema and non-functional requirements for clients and servers (e.g., minimum 2470 / recommended support for resource instances). 2471
This sub-section may also include application guidelines germane to sleepy HAN devices. 2472
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 75 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
10.1.4 LogEvents 2473
This sub-section includes definitions of all LogEvents that may be raised by the function set. Note that 2474 function sets locally define their own LogEvent cardinal values, which typically will not be unique 2475 across function sets. The function set specific LogEvent codes are combined with a function set 2476 identifier to produce a unique code. 2477
All LogEvent definitions are presented in the format shown by Table 10-2. 2478
Table 10-2 Example LogEvents. 2479
LogEvent Name LogEvent Code LogEvent Description
LE_EXAMPLE_0 0x00 Normative text defining when the event should be generated.
LE_EXAMPLE_1 0x01 Normative text defining when the event should be generated.
10.2 Device Capabilities Function Set 2480
10.2.1 Overview 2481
The DeviceCapability resource enumerates the function sets supported by a device and can be used by 2482 clients to discover location information for the enumerated function sets. 2483
10.2.2 List Ordering 2484
This resource does not contain any lists so no page ordering is specified. 2485
10.2.3 Application Guidelines / Behavior 2486
Smart Energy 2 clients locate HAN services by performing DNS Service Discovery (DNS-SD) queries 2487 to the HAN. A query may be issued non-specifically for any Smart Energy 2 device, or a Smart Energy 2488 2 device supporting a specific function set. Successful DNS-SD queries return the URI to the matching 2489 server's DeviceCapability resource. The client is then free to further access the function sets enumerated 2490 within the DeviceCapability resource. 2491
Clients MAY query this resource to determine what resources are available on the given server. The 2492 resources a server exposes MAY be determined by the access rights of the client on this server. Servers 2493 MAY hide resources that a client does not have access rights to. For an alternative way to locate 2494 resources see the sections on End Device and Function Set Assignments. 2495
A resource serving device (i.e., all servers) SHALL implement the DeviceCapability resource. 2496
10.2.4 LogEvents 2497
There are no LogEvents generated by this function set. 2498
10.3 Self Device Resource 2499
10.3.1 Overview 2500
The SelfDevice resource provides an interface for servers to publish general information about 2501 themselves (e.g., SFDI, LFDI, software version numbers). 2502
10.3.2 List Ordering 2503
This resource does not contain any lists so no ordering is specified. 2504
10.3.3 Application Guidelines / Behavior 2505
If a server hosts resources pointed to from a SelfDevice instance (e.g., DeviceInformation via 2506 DeviceInformationLink, PowerStatus via PowerStatusLink), those resources SHOULD be restricted to 2507
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 76 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
read-only access. That is, even if the SEP 2 WADL allows PUT, POST, or DELETE access, those 2508 HTTP methods SHOULD be blocked (or restricted to access by the server itself, i.e. through a loop-back 2509 interface). 2510
Exceptions to the above recommendation are as follows: 2511
� Self Device servers MAY allow read / write access to the resource pointed to by 2512 ConfigurationLink. 2513
10.3.4 LogEvents 2514 Table 10-3 Self Device LogEvents. 2515
LogEvent Name LogEvent Code LogEvent Description
SE_INVALID_WRITE_TO_SELF 0x00 MAY be generated in response to PUT, POST, DELETE attempts on the SelfDevice instance or any of its write-protected sub-resources.
10.4 End Device Resource 2516
10.4.1 Overview 2517
The EndDevice function set provides interfaces to exchange information related to particular client 2518 device(s). This may include both general information about a client (e.g., SFDI, software version 2519 numbers) and information specific to the relationship between a client and the server where the 2520 EndDevice resource is hosted (e.g., subscriptions, function set assignments, registration). The major 2521 resources are listed below: 2522
� EndDeviceList 2523
� EndDevice 2524
EndDeviceList provides the list of all EndDevice resources hosted by the given server. Each EndDevice 2525 resource corresponds to a particular client device for which the server is maintaining persistent 2526 information. On an EndDevice function set server, an EndDevice resource may be created as part of an 2527 out-of-band registration process. EndDevice resources may also be created on a POST to the 2528 EndDeviceList. 2529
10.4.2 List Ordering 2530 Table 10-4 End Device List Ordering. 2531
Resource Name Primary Key Secondary Key Tertiary Key
EndDevice SFDI (ascending)
href (ascending)
N/A
10.4.3 Application Guidelines / Behavior 2532
Servers MAY present the EndDeviceList differently based on the credentials of the requesting client. 2533 For example, even if a server contains the EndDevice resources for five registered clients, any one 2534 registered client that GETs the EndDeviceList may receive a list resource containing only the one 2535 EndDevice resource corresponding to that client. Similarly, an unregistered client that GETs the 2536 EndDeviceList may receive an empty EndDeviceList list resource. However, clients SHALL NOT rely 2537 on this filtering behavior, as it is not mandatory server behavior; therefore, clients SHALL support the 2538 normal paging mechanism for List-type resources. 2539
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 77 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
If a server hosts resources pointed to from an EndDevice instance (e.g., DeviceInformation, 2540 DevicePowerStatus) that allow PUT, POST, or DELETE access, those HTTP methods SHOULD be 2541 restricted to the client device represented by the given EndDevice. 2542
Clients MAY update their EndDevice and related status resources at regular intervals, or when the 2543 relavant information changes, to the appropriate sub-resources of an EndDevice instance that 2544 corresponds to the client. 2545
Clients SHALL NOT POST a new EndDevice instance to a server's EndDeviceList if that 2546 EndDeviceList already contains an EndDevice instance for the client. 2547
It is RECOMMENDED that servers remove records after 72 hours of no activity from the corresponding 2548 client. It is RECOMMENDED that clients POST at least once every 48 hours. 2549
Servers SHOULD delete or prevent duplicate EndDevice instances for the same client from appearing in 2550 its EndDeviceList. For instance, certificate information transmitted as part of TLS may be used to 2551 uniquely identify a particular client and prevent it from POSTing multiple EndDevice instances. 2552
Servers MAY remove EndDevice instances and / or their subordinate resources at any time, for any 2553 reason. Clients that have cached URIs for their EndDevice instance and / or subordinate resources but 2554 are no longer able to access those resources SHOULD attempt to rediscover the new locations of those 2555 resources, recognizing that they MAY have been permanently deleted by the server (e.g., as part of an 2556 out-of-band de-registration process). 2557
When a Server receives an EndDevice resource via a POST to its EndDeviceList, the Server SHOULD 2558 NOT modify any of the Link attributes inherited from AbstractDevice if the Link contains a fully 2559 qualified URI. If a POSTed Link does not contain a fully qualified URI, the Server MAY allocate local 2560 storage for that subordinate resource and populate the EndDevice resource with a Link pointing to the 2561 allocated resource, or the Server MAY choose not to support that particular subordinate resource, if 2562 allowed by the SEP 2 schema, in which case that particular Link attribute would not appear in the newly 2563 created EndDevice resource. 2564
Clients that POST EndDevice resources to the EndDeviceList of a Server SHOULD NOT populate Link 2565 attributes in that EndDevice resource with fully qualified URIs that point to resources on the Server 2566 itself. Servers would typically allocate storage and URIs themselves. 2567
10.4.4 LogEvents 2568 Table 10-5 End Device LogEvents. 2569
LogEvent Name LogEvent Code LogEvent Description
LE_UNAUTHORIZED_WRITE_TO_END_DEVICE 0x00 MAY be generated in response to PUT, POST, and DELETE attempts by an unauthorized device on an EndDevice instance or any of its protected sub-resources.
10.5 Function Set Assignments 2570
10.5.1 Overview 2571
The FunctionSetAssignments resource defines collections of references to function set instances. These 2572 collections are used by the End Device resource for indicating to devices the resources that are to be 2573 used for specific purposes. For example, a service provider may wish that all the participants of a 2574
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 78 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
particular program use a given DRLC function set instance, Time resource, and Pricing function set 2575 instance. A FunctionSetAssignments resource contains references to the function set instances that are to 2576 be used by the assigned device(s). 2577
10.5.2 List Ordering 2578 Table 10-6 Function Set Assignments List Ordering. 2579
Resource Name Primary Key Secondary Key Tertiary Key
FunctionSetAssignments mRID (descending)
NA NA
10.5.3 Application Guidelines / Behavior 2580
The Function Set Assignments function set is a means to indicate collections of particular instances of 2581 function sets. Each instance of the Function Set Assignments function set contains lists of references to 2582 particular function set instances. Service providers, HEMS, and possibly other entities MAY use this 2583 service. They MAY create these instances based on a HAN asset class / category, service provider 2584 program, or any other criteria. 2585 2586 Specific instances of FunctionSetAssignments resources are defined out of band and the methods for 2587 getting the information into the instances is outside the scope of this specification. Server use of this 2588 function set is OPTIONAL. Clients that act on events SHALL determine if they are assigned into 2589 Function Set Assignments. Clients MAY be assigned multiple Function Set Assignments. Multiple 2590 Clients MAY be assigned the same Function Set Assignment. If a server supports Function Set 2591 Assignments it SHALL support a minimum of 1 Function Set Assignments for each HAN device 2592 registered to the server. A server SHOULD support 3 Function Set Assignments for each HAN device. 2593 Clients SHALL support at least 6 function set instances (e.g., two DemandResponseProgram instances, 2594 one Time instance, one TariffProfile instance, and two MessagingProgram instances) assigned through 1 2595 or more Function Set Assignments. 2596 2597 If a FunctionSetAssignments instance contains references to time-responsive function sets, it MUST 2598 also include a reference to a Time resource. 2599 2600 Clients SHALL identify which Function Set Assignments apply to them by querying the 2601 FunctionSetAssignments resource within their End Device function set instance (see the End Device 2602 section for more details). 2603 2604 Clients SHALL periodically poll their group assignments under their EndDevice resource (e.g., 2605 /edev/{#}/fsa), and the corresponding Function Set Assignments resource (e.g. /fsa/{#}), or SHALL 2606 subscribe to them to monitor for changes. Client devices that do not subscribe SHALL query at least 2607 once every 24 hours but SHALL NOT query more than once per hour. 2608
10.5.4 LogEvents 2609
There are no LogEvents generated by this function set. 2610
10.6 Subscription / Notification Mechanism 2611
10.6.1 Overview 2612
This section describes the design and use of resources that support a generic, lightweight subscription / 2613 notification mechanism for use throughout the specification. This mechanism may be useful when a 2614 client wishes to quickly learn of changes to a resource on a server. 2615
The following text further clarifies the roles of the subscription and notification resources. 2616
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 79 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
10.6.2 List Ordering 2617
Notification resources typically are not exposed such that they can be read over the Smart Energy 2618 network, but devices that do choose to expose the resource(s) MUST obey the list ordering rules below. 2619
Table 10-7 Subscription / Notification List Ordering. 2620
Resource Name Primary Key Secondary Key Tertiary Key
Subscription href (ascending)
NA NA
Notification href (ascending)
NA NA
10.6.3 Application Guidelines / Behavior 2621
10.6.3.1 Subscription Resource 2622
A subscription resource is realized as a resource for an individual client, providing interfaces to all 2623 subscriptions for the given client. A server indicates support of subscriptions for a given resource with 2624 the subscribable attribute of that resource. 2625
10.6.3.2 Notification Resource 2626
The notification resource is used to receive notifications that a resource to which a host is subscribed has 2627 changed. The location of the notification resource is passed to the subscription server in the body of the 2628 subscription. As such, a given client (notification resource server) may have one notification resource 2629 for multiple different notifications or may have a different notification resource for different 2630 notifications. The resource representation returned in a notification SHALL be identical to that which 2631 would be returned via a GET request to the resource, subject to the limit parameter discussed below and 2632 per the rules stated earlier in this specification for representing resources. 2633
While some notification servers (subscription clients) may support reusing a TLS connection as a client 2634 for notifications, this mechanism is not reliable as a TLS session may have ended. Notification servers 2635 (subscription clients) SHALL support TLS as a server if they wish to receive secure notifications. 2636
10.6.3.3 Conditional Subscription / Report by Exception 2637
If allowed by the specific function set, some resources can have conditional subscriptions to enable a 2638 report by exception capability. The following conditions are allowed and are specified in the 2639 subscription: 2640
� Lower Threshold – used to cause a notification when the resource's value is below the given 2641 value. 2642
� Upper Threshold – used to cause a notification when the resource's value is above the given 2643 value. 2644
Note, both an upper threshold and a lower threshold may be specified for a given subscription. If both 2645 an upper threshold and a lower threshold are specified, the upper threshold SHALL be greater than the 2646 lower threshold, otherwise an error representation SHALL be returned. 2647
If neither a lower threshold nor an upper threshold is specified, then a server SHALL send a notification 2648 whenever the resource to which the client is subscribed changes. If a lower threshold and / or an upper 2649 threshold are specified, then a server SHALL send a notification whenever the appropriate value crosses 2650 (in either direction) the appropriate threshold for the resource to which the client is subscribed. Servers 2651 that support subscriptions to a given resource MAY support conditional subscriptions to that resource. 2652
For a given resource, to determine the attribute on which the conditions apply, the attributeIdentifier 2653 attribute is used. 2654
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 80 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
10.6.3.4 Subscription Rules 2655
A subscription renewal is a subscription to the same resource from the same client, regardless of 2656 subscription parameters. 2657
1) Clients SHOULD send subscription renewals every 24 hours, and no more often than every 1 2658 hour, to sustain a subscription. 2659
2) Servers MAY remove subscriptions at any time. 2660 3) Servers SHOULD remove subscriptions if a client has not renewed in 36 hours. 2661 4) Subscriptions SHALL be maintained on servers through power loss. 2662 5) Servers SHALL use the subscription parameters from the latest subscription renewal. 2663 6) Clients SHOULD poll after perceived loss of connectivity. 2664 7) If the URI of a resource changes, then subscriptions to that resource SHALL be terminated. 2665 8) For subscriptions to non-list resources, a notification SHALL be sent whenever the 2666
representation of the non-list resource changes. 2667 9) For subscriptions to list resources, a notification SHALL be sent whenever any subordinate 2668
resources are added to or removed from the list, or if the representation of those subordinate 2669 resources change. As a result, if a client is subscribed to both an event and a list containing that 2670
event, the client will receive two notifications should that event change. See Section 6.7 6.7for 2671
more information. 2672 a. It should be noted that notifications for list resources are an exception where certain list 2673
attributes are included (e.g., all and results) that would normally not be present when a 2674 list resource is provided in a POST. 2675
10) To prevent overwhelming network resources, notifications SHOULD be sent to a given client 2676 for a given resource no more than once every 30 seconds. Notifications for conditional 2677 subscriptions SHOULD only be sent once within this time period for a given client for a given 2678 resource and any additional notifications SHOULD NOT be queued. All devices need to be 2679 considerate of network resources. 2680
11) Servers implementing the subscription resource SHALL be capable of maintaining a minimum 2681 of 1 subscription and servers implementing the subscription resource SHOULD support at least 2682 1 subscription per device per subscribable resource. 2683
12) If a server implementing the subscription resource is unable to accept a subscription, the server 2684 SHALL return an error resource representation indicating the specific error (e.g., element does 2685 not support conditional subscription) with an HTTP response code of 400. 2686
13) When a server removes or terminates a subscription, it SHALL send the client a terminate 2687 subscription (except after an error from an undesired subscription, as mentioned in rule 14 2688 below). The server SHALL send a Notification to the client's "Post URI" for the affected 2689 subscription. The Resource contained in the Notification SHALL be a Subscription, containing a 2690 Status element identifying the reason for terminating the subscription. When a subscription is 2691 terminated because the subscribed resource has moved, servers MAY include newResourceURI 2692 in the subscription termination message, indicating the resource's new location. 2693
14) If a client receives a notification for an undesired subscription, the client SHALL return an 2694 HTTP 400 error. Upon receipt of such an error, the server SHALL remove the subscription 2695 without notification. 2696
15) Servers SHOULD allow only the end device that corresponds to a given EndDevice resource to 2697 modify the subscriptions within that resource. 2698
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 81 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
16) The default recommended policy is that subscription management SHOULD be performed 2699 using TLS. 2700
10.6.4 LogEvents 2701 Table 10-8 Subscription / Notification LogEvents. 2702
LogEvent Name LogEvent Code LogEvent Description
SUB_NTFY_FAIL 0x00 SHOULD be issued when there is a failure to successfully send a Notification (after a successful connection).
SUB_CONN_ESTB_FAIL 0x01 SHOULD be issued when there is a failure to successfully establish a connection to send a Notification.
10.7 Response 2703
10.7.1 Overview 2704
This function set provides an interface for capturing Responses from all events, including Demand 2705 Response (DRLC), Distributed Energy Resources (DER), Pricing, and Messaging. Client devices of this 2706 function set include Smart Thermostats, IHDs, Energy management systems and devices that support 2707 load control, pricing or text events. 2708
The originating event will indicate if a response is required. 2709
10.7.2 List Ordering 2710 Table 10-9 Response List Ordering. 2711
Resource Name Primary Key Secondary Key Tertiary Key
ResponseSet mRID (descending)
NA NA
Response createdDateTime (descending)
endDeviceLFDI (ascending)
NA
10.7.3 Application Guidelines / Behavior 2712
The typical use for this function set is that end devices will POST their responses to a Response resource 2713 identified in events. It is not expected that devices will use discovery to locate these resources. 2714
It is up to the implementer to decide whether to have all responses in a single list or to have multiple 2715 lists. The destination of the Responses is controlled by the replyTo attribute of the originating event. 2716
If a response is desired to an event, then the event SHALL provide, in the replyTo field, a URI 2717 indicating the location of where the responses are to be posted. 2718
The client SHALL POST the responses to the indicated URI based on the rules indicated by the 2719 responseRequired bitfield of the event. 2720
If a server hosts events that specify a response is required then that server is NOT REQUIRED to host 2721 the response server. 2722
The Response Server identified in the replyTo field of the event SHOULD be available on the network. 2723
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 82 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Several function sets use the responseRequired attribute, which indicates whether or not this particular 2724 event requires a response from the client. The following table indicates the valid Response.type values 2725 supported by each function set: 2726
Table 10-10 Response Types by Function Set. 2727
Enu
mer
atio
n V
alue
Des
crip
tion
Why
Sen
t
Whe
n Se
nt
resp
onse
Requ
ired
bit p
ositi
on
DR
LC
and
DE
R
Pric
ing
Mes
sagi
ng
0 Reserved
1 Event received To notify response server that client has initially received event.
When the device first receives the event, either via a GET or a Notification.
0 X X X
2 Event started To notify response server that client has begun event.
At EffectiveStartTime (see Section 12.1.3.1)
1 X X X
3 Event completed
To notify response server that the event fully and successfully completed.
At EffectiveEndTime (see Section 12.1.3.1)
1 X X X
4 User has chosen to opt-out
To notify response server that user has chosen to opt out of the event. Can occur before event begins.
At time user actively chose to opt out or when device automatically opts out due to user preference.
1 X
5 User has chosen to opt-in
To notify response server that user has chosen to opt in to the event (after a previous opt-out). Can occur before event begins.
At time user actively chose to opt in or when device automatically opts in due to user preference.
1 X
6 The event has been cancelled
To notify response server that client has initially received cancellation.
When the device first receives the cancellation, either via a GET or a Notification, even if the event has not yet begun execution.
1 X X X
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 83 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Enu
mer
atio
n V
alue
Des
crip
tion
Why
Sen
t
Whe
n Se
nt
resp
onse
Requ
ired
bit p
ositi
on
DR
LC
and
DE
R
Pric
ing
Mes
sagi
ng
7 The event has been superseded
To notify response server that client has learned of an event that supersedes this event.
When the device first learns of an event that supersedes this event, even if the event has not yet begun execution.
1 X X X
8 Event partially completed with user opt-out
To notify response server that some participation in the event occurred, but not complete participation, due to one or more user opt-outs.
At EffectiveEndTime (see Section 12.1.3.1)
1 X
9 Event partially completed due to user opt-in
To notify response server that some participation in the event occurred, but not complete participation, due to one or more user opt-ins (after a previous opt-out).
At EffectiveEndTime (see Section 12.1.3.1)
1 X
10 Event completed, no user participation (previous opt-out)
To notify response server that no participation in the event occurred.
At EffectiveEndTime (see Section 12.1.3.1)
1 X
11 User has acknowledged the event
To notify response server that the client displayed the event and a human user actively acknowledged it.
At time user actively chose to acknowledge the event.
2 X X X
12 Cannot be displayed
To notify response server that the client is unable to display the message.
When the device first receives the event, either via a GET or a Notification.
1 X
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 84 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Enu
mer
atio
n V
alue
Des
crip
tion
Why
Sen
t
Whe
n Se
nt
resp
onse
Requ
ired
bit p
ositi
on
DR
LC
and
DE
R
Pric
ing
Mes
sagi
ng
13 Event aborted due to alternate provider event
To notify response server that the client has chosen to stop execution of the event and instead execute an event from a different service provider.
At time the original event was ceased.
1 X X X
14 - 251 Reserved
252 Rejected – control parameter not applicable
To notify response server that client is unable to execute the event due to the controls being inapplicable to the device (e.g., a temperature offset was sent to a pool pump).
When the device first receives the event, either via a GET or a notification.
1 X
253 Rejected – invalid event
To notify response server that client is unable to execute the event due to the controls (e.g., duty cycle, offset, setpoint) being out of range or not possible for the device (e.g., settings already at a maximum or minimum).
When the device first receives the event, either via a GET or a notification.
1 X
254 Rejected – event was received after it expired
To notify response server that client has initially received event, but that the event was received after SpecifiedEndTime.
When the device first receives the event, either via a GET or a Notification.
1 X X X
255 Reserved
10.7.3.1 Response Storage 2728
It is expected that the server provides some mechanism that allows the service provider to obtain the 2729 responses, even in the presence of outages. Details of storage are vendor specific. 2730
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 85 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Implementers SHOULD have enough storage and bandwidth to support responses for the number of 2731 devices they plan to support as a server for each function set that requires a response. 2732
If the server supports the GET method for the response function set it SHALL minimally support 1 2733 response for each function set for which it accepts responses. 2734
10.7.4 LogEvents 2735 Table 10-11 Response LogEvents. 2736
LogEvent Name LogEvent Code
LogEvent Description
RESPONSE_LIST_OVERFLOW 0x00 Should be issued by a server anytime their response list has exceeded maximum storage.
RESPONSES_REPORTED_UPSTREAM 0x01 Should be issued by a server when responses are sent upstream.
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 86 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
11 Common Resources 2737
This section defines the resources and function sets that provide general purpose, non-domain specific 2738 functionality. 2739
11.1 Time Function Set 2740
11.1.1 Overview 2741
Devices synchronize their time source by locating and acquiring time from a Time resource. Time 2742 synchronization of devices is required to effectively support DRLC, pricing changes, time stamping of 2743 metering data, etc. 2744
Devices implementing the Time resource obtain correct time either directly from an external 2745 authoritative time source (e.g., NTP) or indirectly from an inaccurate source (e.g., manually entered via 2746 UI). 2747
There may be a dependency upon an external time source for UTC time (NTP service, etc.). 2748
11.1.2 List Ordering 2749
This resource does not contain any lists so no ordering is specified. 2750
11.1.3 Application Guidelines / Behavior 2751
All devices SHALL implement the Time function set as a resource server, or a client, or both. 2752
All communication of time used throughout the specification, with the exception of time for user 2753 display, SHALL be according to the definition of TimeType. Devices with user displays SHALL 2754 support local time and daylight savings time offsets. 2755
If FunctionSetAssignments contain both Event-based function sets (e.g., DRLC, pricing, message) and a 2756 Time resource then devices SHALL use the Time resource from the same FunctionSetAssignments 2757 when executing the events from the associated Event-based function set. 2758
For example, if there are two FunctionSetAssignments 'A' and 'B', where 'A' contains a DRLC function 2759 set (DRLC(A)) and a Time resource (Time(A)) and 'B' contains a DRLC function set (DRLC(B)) and a 2760 Time resource (Time(B)), then events from DRLC(A) will be executed using Time(A) as their Time 2761 resource and events from DRLC(B) will be executed using Time(B) as their Time resource, regardless 2762 of the quality metrics of either Time resource. 2763
If a device is not assigned a Time resource, it MAY discover and operate Event-based function sets. 2764 When the device executes these events, the device SHALL use the Time resource from the server device 2765 from which it received the event. If a client discovers an Event-based function set and cannot also 2766 retrieve a Time resource from this same server, it SHALL NOT act on the events from this Event-based 2767 function set. 2768
If a device is not processing events it SHALL discover and choose the Time resource with the best 2769 quality metric. 2770
If a device displays time then it SHOULD display the time with the highest quality metric from one of 2771 the above-acquired Time resources. For devices displaying time, it should be noted that the Time 2772 resource with the highest quality metric may differ from the Time resource(s) used by events (e.g., a 2773 service provider's Time resource may "true-up" at the end of a billing cycle). Devices SHOULD either 2774 convert displayed event times to be consistent with the chosen Time resource or make it clear to users 2775 that there are Time resource differences. 2776
Some service providers operate a given asset on a time standard that differs from the definition given for 2777 TimeType. This would be an intentionally uncoordinated time. If a time server serves an intentionally 2778
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 87 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
uncoordinated time in the currentTime field, it SHALL have a quality metric of 7 - time intentionally 2779 uncoordinated. 2780
See the XML schema described in [ZB 13-0201] for details of the quality metric. 2781
Devices SHOULD periodically query the selected Time resources and compare the response with the 2782 local device time to determine local clock accuracy. 2783
A device SHOULD manage the frequency of its Time resource updates and subsequent local clock 2784 updates to provide local time accurate to within: 2785
1) 10 seconds per 24 hour period for devices displaying time to the user. 2786
2) 60 seconds per 24 hour period if there is no user interface. 2787
To maintain time synchronization, devices SHOULD maintain these accuracies via Time resource 2788 requests. To keep network traffic to a minimum this polling SHALL be no more than once per 15 2789 minutes once a valid time source has been established. Requests SHALL NOT exceed once per 15 2790 seconds and SHALL employ exponential back off prior to establishing a valid time source. These 2791 requirements apply on a per time server basis. 2792
Time related configuration is handled within the Configuration resource. 2793
Time adjustments less than 60 seconds SHALL never be made backwards (e.g., use stall time or long 2794 seconds to correct for being ahead on time). 2795
11.1.4 LogEvents 2796 Table 11-1 Time LogEvents. 2797
LogEvent Name LogEvent Code LogEvent Description
TM_TIME_ADJUSTED 0x00 Should be issued by a server when its time is adjusted.
TM_TIME_SOURCE_CHANGED 0x01 Should be issued by a client when it chooses a different primary time source.
11.2 DeviceInformation Function Set 2798
11.2.1 Overview 2799
The DeviceInformation function set provides static manufacturer specific information about a device. 2800
11.2.2 List Ordering 2801
This resource does not contain any lists so no ordering is specified. 2802
11.2.3 Application Guidelines / Behavior 2803
The DeviceInformation function set is used to provide information about the actual device. Any device 2804 that implements a HTTP server to serve resources SHALL implement the DeviceInformation resource 2805 (this does not apply to devices that only serve Notification / NotificationList resources for the purpose of 2806 receiving subscription notifications). Client devices that do not implement a HTTP server are not 2807 required to serve the DeviceInformation function set. However this information MAY be posted to the 2808 appropriate EndDevice resource on an EndDevice function set server. 2809
11.2.4 LogEvents 2810
There are no LogEvents generated by this function set. 2811
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 88 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
11.3 Power Status 2812
11.3.1 Overview 2813
The PowerStatus resource provides information regarding a device's current power source, as well as 2814 basic status regarding any battery installed within the device. 2815
11.3.2 List Ordering 2816
This resource does not contain any lists so no ordering is specified. 2817
11.3.3 Application Guidelines / Behavior 2818
The content of this resource will change as the device switches power sources (mains to battery, battery 2819 to mains) and as the battery charges / discharges. 2820
11.3.4 LogEvents 2821 Table 11-2 Power Status LogEvents. 2822
LogEvent Name LogEvent Code LogEvent Description
PS_LOW_BATTERY 0x00 Should be issued when the installed battery charge drops below the configured low battery charge threshold.
11.4 Network Status 2823
11.4.1 Overview 2824
The Network Status function set provides information regarding the device's network (IP) layer, and 2825 potentially link layer, performance. 2826
The design of this function set is intended to allow a single network (IP) layer interface to be linked with 2827 multiple link layer interfaces (as is often the case with devices that provide L2 bridging) as well as to 2828 allow multiple network (IP) layer interfaces to be linked with a single link layer interface. 2829
Several references were consulted in the generation of the design and attributes of this function set, 2830 including: [RFC 2863], [RFC 4293], [RFC 3635], [DOCSIS], and [Linux]. 2831
The resources of this function set can also serve as an example for others to create additional network 2832 status information in a separate namespace (e.g., for other link layers). 2833
11.4.2 List Ordering 2834 Table 11-3 Network Status List Ordering. 2835
Resource Name Primary Key Secondary Key Tertiary Key
IPInterface ifIndex (ascending) NA NA
IPAddr address (ascending) NA NA
LLInterface EUI64 (ascending) NA NA
RPLInstance DODAGid (ascending)
RPLInstanceID (ascending) NA
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 89 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Resource Name Primary Key Secondary Key Tertiary Key
RPLSourceRoutes SourceRoute (ascending)
DestAddress (ascending) NA
2836
11.4.3 Application Guidelines / Behavior 2837
This function set does not have any specific application guidelines / behavior beyond those already 2838 specified in the schema. 2839
11.4.4 LogEvents 2840 Table 11-4 Network Status LogEvents 2841
LogEvent Name LogEvent Code LogEvent Description
NS_JOIN_UNSP 0x00 SHOULD be issued when the device joins an unspecified network
NS_LVE_UNSP 0x01 SHOULD be issued when the device leaves an unspecified network
NS_JOIN_802_3 0x02 SHOULD be issued when the device joins an IEEE 802.3 (Ethernet) network
NS_LVE_802_3 0x03 SHOULD be issued when the device leaves an IEEE 802.3 (Ethernet) network
NS_JOIN_802_11 0x04 SHOULD be issued when the device joins an IEEE 802.11 (WLAN) network
NS_LVE_802_11 0x05 SHOULD be issued when the device leaves an IEEE 802.11 (WLAN) network
NS_JOIN_802_15 0x06 SHOULD be issued when the device joins an IEEE 802.15 (PAN) network
NS_LVE_802_15 0x07 SHOULD be issued when the device leaves an IEEE 802.15 (PAN) network
NS_JOIN_1901 0x08 SHOULD be issued when the device joins an IEEE 1901 (PLC) network
NS_LVE_1901 0x09 SHOULD be issued when the device leaves an IEEE 1901 (PLC) network
11.5 LogEvent List 2842
11.5.1 Overview 2843
The LogEvent List contains a list of time-stamped instances of LogEvents generated by the device. 2844 LogEvents are typically asynchronously generated warnings of some out of bounds condition or unusual 2845 significant event detected by the device. For example, the device's battery charge falling below an 2846 operator designated low charge threshold. 2847
11.5.2 List Ordering 2848 Table 11-5 LogEvent List Ordering. 2849
Resource Name Primary Key Secondary Key Tertiary Key
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 90 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Resource Name Primary Key Secondary Key Tertiary Key
LogEvent createdDateTime (descending)
LogEventID (descending)
NA
2850
11.5.3 Application Guidelines / Behavior 2851
The number of LogEvents supported within the LogEvent List SHALL be vendor dependent. LogEvent 2852 server devices SHALL be capable of internally storing and supporting at least 10 unique LogEvent 2853 instances. When a new LogEvent is issued, it SHALL be added as the first entry in the LogEvent List. If 2854 the log is full, the oldest LogEvent SHOULD be removed to make room for the latest incoming 2855 LogEvent. 2856
LogEvent List is OPTIONAL for both servers and clients. 2857
LogEvents SHALL be time stamped when they are added to the LogEventList. A server device therefore 2858 needs a time source, and should be using the highest quality Time resource it can obtain from the HAN. 2859
A LogEvent SHALL be ZigBee Alliance defined or vendor defined or defined within other profiles. 2860
11.5.3.1 LogEvents 2861
There are no LogEvents generated by this function set. 2862
The table below presents the LogEvent codes allocated by the ZigBee Alliance for general Smart Energy 2863 2 events. These codes are associated with the value of zero (General) in the functionSet field. 2864
Table 11-6 General LogEvents. 2865
LogEvent Name LogEvent Code LogEvent Description
LE_GEN_HARDWARE 0x00 Unclassified general hardware fault occurred.
LE_GEN_SOFTWARE 0x01 Unclassified general software fault occurred.
Note: See the function set definitions for LogEvent Codes associated with each function set. 2866
11.6 Configuration Resource 2867
11.6.1 Overview 2868
The Configuration resource implements centralized read / write access to the device's operational 2869 configuration. This resource may be queried to provide current device configuration, perform 2870 configuration backup, etc. This resource is modified as needed to control the operation of the device. 2871
This resource adheres to the recommendations outlined in [RFC 3535]. Specifically, configuration is 2872 best separated from operational state and performance statistics to ease configuration retrieval, 2873 conformance check, and placement / modification to the device. In other words, it is easier to manage 2874 device configuration via a single resource than having to collect, collate, and update configuration 2875 parameters from multiple resources spread across a SEP 2 implementation. 2876
11.6.2 List Ordering 2877
This resource does not contain any lists so no ordering is specified. 2878
11.6.3 Application Guidelines / Behavior 2879
It is strongly RECOMMENDED that devices persist configuration data across a power cycle. 2880
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 91 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
11.6.4 LogEvents 2881 Table 11-7 Configuration LogEvents. 2882
LogEvent Name LogEvent Code LogEvent Description
CFG_CONFIGURATION_UPDATED 0x00 SHALL be issued when the local Configuration resource is changed.
11.7 File Download Function Set 2883
This section describes the mechanisms used to support secure, interoperable, remote software download 2884 to Smart Energy Profile 2.0 devices. This function set may also be used for remote download of other 2885 file artifacts such as log files, configuration files, security credential files, etc. Three resources constitute 2886 the File Download Function Set: the FileList resource, the File resource, and the FileStatus resource. 2887
There are two primary actors involved in a file download: the Loading Device (LD) and the File Server 2888 (FS). A FS is any device serving this function set. 2889
To accommodate sleepy end devices, SEP 2 supports only a polled mode of file download. 2890
11.7.1 File List Resource 2891
11.7.1.1 Overview 2892
A FileList resource contains zero or more File resources available to be loaded by client devices. A File 2893 resource contains various meta data describing the file and a link to the file binary artifact. 2894
11.7.1.2 List Ordering 2895
File resources are ordered within a FileList as follows: 2896
Table 11-8 File Download List Ordering. 2897
Resource Name Primary Key Secondary Key Tertiary Key Quaternary Key
File mfID (ascending)
mfModel (ascending)
mfVer (descending)
href (ascending)
The main use case for this ordering is to enable client devices (of specific manufacturer and model) to 2898 query the FileList for available file types with a version newer than the file currently on the device. 2899
11.7.1.3 Application Guidelines / Behavior 2900
This specification designates files resident on the LD as activated or non-activated. A non-activated file 2901 is a file that has been physically loaded onto the LD, but not yet placed into operation. An activated file 2902 is a file that has been both physically loaded onto the LD and placed into operation. An example use of 2903 the activation state is the scenario in which an operator first must load and confirm load of new software 2904 images to a large set of devices (as non-activated, not running) before setting that software image to an 2905 activated state (the running image). 2906
A FileList MUST contain File resources for each file made available by the FS for download by LDs. 2907 The FileList MAY be discoverable as specific to a device (FunctionSetAssignment accessed via an 2908 EndDevice) and / or MAY be discoverable to all devices via DeviceCapabilities. 2909
The LD issues discovery requests to locate available FS (DNS-SD subtype "file"). The LD MUST first 2910 determine if there exists a FunctionSetAssignment, containing a FileList, for the device. If such a 2911 FileList exists, the LD MUST use this FileList exclusively. If a Time resource is specified within this 2912 same FunctionSetAssignment, the LD MUST use this Time resource as the reference for file activation 2913
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 92 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
time. If the LD does not locate a FunctionSetAssignment directing the LD to a specific FileList, the LD 2914 MUST attempt discovery of a FileList provided by any device's DeviceCapabilities resource. 2915
If the LD locates more than one File resource satisfying its File query, it is up to the LD to determine the 2916 appropriate File selection. Any algorithm used to make this selection is out of scope of this 2917 specification. 2918
If the LD is unable to make a selection between multiple files, the LD SHOULD issue an 2919 FE_FILE_MULTIPLE_FILES LogEvent. 2920
An LD MUST poll for available files at least once every 24 hours. 2921
File content is transferred using either HTTP or HTTPS. The latter SHOULD be used when encryption 2922 over the air / wire is desired. The choice is left to the manufacturer. An LD SHALL provide the ability 2923 to fully receive and store a non-activated file while the current activated file remains operational. For 2924 example, an LD SHALL be able to load a new software image (a non-activated file) while the current 2925 software image executes. In the case of a software image, the activated file is the running image. 2926
SEP 2 deployments could contain clients and servers of vastly differing capabilities: from constrained 2927 embedded devices to cloud-based services. It is thus important that FSs and LDs be provided ways to 2928 control the rate at which files are transferred. The HTTP Range and Content-Range entity headers are 2929 used to support incremental loading of large files. LDs SHOULD use the Range entity header, within 2930 HTTP GET requests for file content, to support file loading via a sequence of one or more HTTP 2931 requests. An FS MUST be able to process the Range entity header within HTTP GET requests for file 2932 content, and MUST support Range entity header processing for at least a single range of bytes. An FS 2933 MUST include the Content-Range entity header within HTTP responses for file content when an LD 2934 requests a specific range. An LD SHOULD be able to process Content-Range entity headers within 2935 HTTP responses for file content. 2936
The HTTP Etag entity header is used to allow LDs to detect any modification to a resource. This is of 2937 particular importance to detect changes in file content during a long running (multi-GET) file load. An 2938 FS MUST maintain a unique entity-tag value for each version of a file referenced by a specific URI. Per 2939 [RFC 2616], the entity-tag value MUST change if the underlying bits of the file change. The FS MUST 2940 include an Etag entity header (indicating the file entity-tag value) in all GET responses containing file 2941 content. An LD MUST detect a change in file Etag value. An LD MUST abort the file load if the Etag 2942 has changed, and SHOULD restart the file load (now based on the new Etag). Note that this approach 2943 for file modification detection was decided, in the general case, to be more bandwidth efficient than 2944 forcing the LD to include an If-Match or If-Range entity header on all GET requests for file content. 2945
For previously loaded, non activated files for which an activation time has not been acquired, the LD 2946 MUST poll the File resource at least once every 24 hours for inclusion of a file activation time. The LD 2947 SHOULD cease attempting to acquire activation time after 5 unsuccessful attempts or if a new File of 2948 same type has been loaded (whichever condition occurs first). If the LD is unable to acquire an 2949 activation time after 5 attempts, the LD MUST cease any further attempts and consider the activation 2950 failed. 2951
An FS SHOULD maintain internal estimates of its current resource usage. If an FS determines that it is 2952 unable to service an incoming HTTP request, the FS SHOULD issue a response indicating 503 error and 2953 SHOULD include the Retry-After entity header (providing guidance to the LD for retry attempt). The 2954 Retry-After entity header SHOULD provide a best estimate as to when the FS expects it will be able to 2955 service the LD request. 2956
An LD SHOULD implement handling for 503 errors and SHOULD implement handling of the Retry-2957 After entity header. If the LD does not support processing of the Retry-After entity header, the LD 2958 MUST wait at least 30 seconds before retrying the file content request. 2959
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 93 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
An LD SHOULD negotiate a desired TCP window size with the FS. 2960
Files SHOULD be treated as raw binary, thus a Content-Type entity header of "application/octet-stream" 2961 SHOULD be used. 2962
11.7.1.3.1 File Formats 2963
SEP 2 makes no requirements upon the internal structure of files. A file is simply a manufacturer-2964 defined sequence of binary octets whose internal details are completely defined by the manufacturer and 2965 out of scope of this specification. 2966
SEP 2 does, however, require a file be digitally signed to protect the file from undetected modification 2967 and provide file origin authentication. 2968
11.7.1.3.2 File Signatures 2969
Files SHALL be signed and signatures verified using approved algorithms specified in [NIST SP800-2970 131A], [NIST SP800-131B], and [NIST SP800-131C]. Cryptographic strength MUST be at least the 2971 minimum specified in [ZB 09-5449] Section 11.3 (which is 128-bit). This specification does not 2972 otherwise prescribe specific cryptographic mechanisms via which the file is signed or signature verified, 2973 does not prescribe the format of the file signing trust chain, and does not prescribe how that trust chain 2974 is managed on the LD. There is no required relationship between the CSEP device trust chain and the 2975 file signing trust chain. The signature of the file SHALL be calculated over the entire contents of the file 2976 excluding the signature octets. 2977
11.7.1.3.3 Loading Files Containing Security Credentials 2978
File loads containing SEP 2 security artifacts (type = 1 or any manufacturer defined file type containing 2979 credentials, key material, etc.) MUST be protected to at least the current level of security associated with 2980 the artifact being loaded. Such a file load MUST be secured using an HTTPS connection. 2981
11.7.1.3.4 File Query Parameters 2982
Beyond the standard SEP 2 list query parameters for result start / length / etc., a FileList supports 2983 additional query parameters to support filtering of Files result sets. These file query parameters, 2984 modeled after several of the elements within the File resource, are: 2985
1) type 2986
2) lFDI 2987
3) mfHwVer 2988
4) mfID 2989
5) mfModel 2990
6) mfSerNum 2991
7) mfVer 2992
All of the query parameter values MUST adhere to identical syntax and semantics as used for the 2993 correspondingly named elements of the File resource described in [ZB 13-0201]. 2994
An FS MUST be able to process all file query parameters. LD usage of any of the file query parameters 2995 is OPTIONAL. 2996
File query parameters MUST be applied to a File List before the standard list query parameters (i.e., the 2997 standard query parameters are used to page the list resulting after the file query parameters are applied). 2998
The set of file query parameters MUST be interpreted as a Boolean expression, with each file query 2999 parameter considered a clause of that expression, and each clause connected by a logical AND operand. 3000
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 94 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Each file query parameter MUST provide an exact match with its File equivalent for its clause to 3001 evaluate to true. There is one exception to this case: the mfVer MUST be evaluated as a GREATER 3002 THAN logical operand versus its File equivalent. 3003
Omission of a query parameter MUST be interpreted as a match, regardless the File's corresponding 3004 value. 3005
11.7.1.4 LogEvents 3006
Loading and activation of files is a long running operation. Diagnosing problems can be challenging. 3007 LDs SHOULD implement the LogEvent Log. If an LD does implement the LogEvents for this function 3008 set, the LD SHALL implement all of the following LogEvents: 3009
Table 11-9 File Download LogEvents. 3010
LogEvent Name LogEvent Code LogEvent Description
FE_FILE_LOAD_FAILED 0x00 This event SHALL be recorded by the LD when it is unable to load a file that was indicated as available by the FS.
FE_FILE_LOAD_OK 0x01 This event SHALL be recorded by the LD when a file is successfully loaded to the LD.
FE_FILE_SIGNATURE_VERIFICATION_FAILED 0x02 This event SHALL be recorded by the LD when it is unable to verify the signature of a loaded file.
FE_FILE_SIGNATURE_VERIFICATION_OK 0x03 This event SHALL be recorded by the LD when a loaded file's signature is successfully verified.
FE_FILE_ACTIVATION_FAILED 0x04 This event SHALL be recorded by the LD when it is unable to activate a previously loaded and signature verified file.
FE_FILE_ACTIVATION_OK 0x05 This event SHALL be recorded when the LD has successfully activated a loaded and signature verified file.
FE_FILE_MULTIPLE_FILES 0x06
This event SHALL be recorded when the LD is unable to determine a single file selection from a set of 2 or more files it has discovered.
11.7.2 File Status Resource 3011
11.7.2.1 Overview 3012
The FileStatus resource enables LDs to provide a means to track the progress of any file load operations 3013 and also a means to diagnose failed file load operations. 3014
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 95 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
11.7.2.2 List Ordering 3015
This resource does not contain any lists so no ordering is specified. 3016
11.7.2.3 Application Guidelines / Behavior 3017
An LD SHOULD implement a SelfFileStatus resource or an LD SHOULD support PUT to a remote 3018 FileStatus (on an EndDevice server). The SelfFileStatus and FileStatus resources SHOULD be updated 3019 whenever a status transition occurs (as a File load and activation flow executes). Status is discussed in 3020 the definition of FileStatus (see [ZB 13-0201]). 3021
11.7.2.4 LogEvents 3022
There are no LogEvents generated by this resource. 3023
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 96 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
12 Smart Energy Resources 3024
This section defines the function sets that are specific to the domain of Smart Energy. The section 3025 begins with a sub-section defining behaviors and discussing issues that are common to several of the 3026 following function set definitions. 3027
12.1 Common Functionality 3028
12.1.1 Overview 3029
This Section describes common application functionality guidelines for features like randomization and 3030 active URIs that apply to more than one function set or in circumstances like adjacent or superseding 3031 events where special cases arise or need clear guidance to result in predictable behavior. 3032
12.1.2 Active List Elements 3033
The Active List Elements of a function set allow client devices to easily find the active instance of a 3034 specific resource. This makes it easier for constrained devices to find the information they are looking 3035 for without the need to explore a large list. Many of the function sets will provide this resource, 3036 including Demand Response, Messaging, and Pricing. 3037
Active lists contain a subset of the instances in the full list of events for a given resource. 3038
12.1.3 Event Rules and Guidelines 3039
These rules and guidelines are meant to specify client behavior in situations in which adjacent, nested, 3040 or overlapping events could cause clients to behave in an unexpected or undesirable manner. 3041
12.1.3.1 Definitions 3042
The following definitions define terms that will be used throughout the Event Rules and Guidelines 3043 section. These terms, when used, are italicized for emphasis. 3044
Event – refers to any instance of a resource with a defined valid duration for which a client should take 3045 action. This would include all resources that are derived from the Event resource defined in the schema 3046 [ZB 13-0201]. 3047
Start Time – Contained within the interval attribute of an Event resource representation and indicates 3048 when the Event should start. 3049
Duration – Contained within the interval attribute of an Event resource representation and indicates for 3050 how long the Event is active. 3051
Specified End Time – Time when an Event completes as specified in the instance's interval attribute. 3052 This is calculated by adding Duration to Start Time. 3053
Scheduled Period - Represents the time between the Start Time and the Specified End Time of the 3054 Event. A Scheduled Period is a Duration anchored at a specific Start Time. 3055
Effective Start Time - Represents the time at which an Event's interval attribute indicates 3056 commencement based on the Start Time plus or minus any applied Start Randomization offsets as 3057 calculated by the Client. 3058
Earliest Effective Start Time - Represents the earliest time at which an Event's interval attribute could 3059 indicate commencement. Calculated as the minimum of Start Time or Start Time plus the Start 3060 Randomization specified by the event. 3061
Effective End Time - Represents the time at which an Event's interval attribute indicates completion 3062 based on the Effective Start Time, plus Duration, plus or minus any applied Duration Randomization 3063 offsets as calculated by the Client. 3064
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 97 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Effective Scheduled Period - Represents the time between the Effective Start Time and the 3065 Effective End Time. 3066
Duration Randomization – The bound on the amount of time to be used when randomizing the 3067 completion of an Event. 3068
Effective Duration - Represents Duration with Duration Randomization applied. 3069
Overlapping Event - Defined as an Event where the Scheduled Period covers part or all of an existing, 3070 previously scheduled Event. 3071
Start Randomization – The bound on the amount of time to be used when randomizing the 3072 commencement of an Event. 3073
Successive Events - When the Start Time plus Duration of the first event is the same as the 3074 Start Time of the second event without randomization. 3075
Nested Events - Defined as two Events where the scheduled Start Time and Specified End Time of the 3076 second Event falls during the Scheduled Period of the first Scheduled Event and the second Event is of 3077 shorter Duration than the first Event. This is an extreme case of Over Lapping Event. 3078
12.1.3.2 Rules and Guidelines 3079
In the text below, some rules and guidelines will be identified as specific to "function sets with direct 3080 control." These function sets exert direct control over clients' behavior and are typically used to manage 3081 service provider infrastructure through incentive programs to the HAN owner. This is in contrast with 3082 informational function sets that provide data to clients for display and awareness purposes such as 3083 Billing, Messaging, and Pricing. Function sets with direct control primarily include Flow Reservation, 3084 DRLC and DER. Pricing is somewhat unique in that it exerts control-like effects upon price responsive 3085 clients; however, it is not a form of direct control from the service provider's point of view. The 3086 following rules and guidelines apply to both types of function sets unless specifically noted. 3087
The depicted behaviors and required application management decisions are driven from the following 3088 guidance and rule set: 3089
1) Clients that act on events that do not subscribe to their Event lists SHALL poll the lists for new 3090 Events at least once every 15 minutes and SHOULD poll at least every 5 minutes. 3091 3092
2) Clients SHALL monitor the active Event(s) for status changes at least once every 15 minutes 3093 and SHOULD monitor at least once every 5 minutes. Note that these resources might be 3094 acquired in meeting requirement 1 above; additional polling might not be needed. 3095 3096
3) Editing Events SHALL NOT be allowed except for updating status. Service providers SHALL 3097 cancel Events that they wish clients to not act upon and / or provide new superseding Events. 3098
4) For function sets with direct control and the Pricing function set, clients SHALL NOT 3099 simultaneously execute or report execution of multiple simultaneous Events. (e.g., Nested 3100 Events and Overlapping Events). The rules below clarify the expected behavior in cases in 3101 which either of these situations arises. 3102
5) A client SHALL consider the current Event complete if a superseding Event is started. 3103
6) When comparing two Nested Events or Overlapping Events, from servers with the same primacy 3104 the creationTime element SHALL be used to determine which Event is newer and therefore 3105 supersedes the older. The Event with the larger (e.g., more recent) creationTimedate-time is the 3106 newer Event. 3107
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 98 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
7) Events presented to the HAN SHOULD make minimum use of Overlapping Events and 3108 Nested Events. Overlapping Events and Nested Events SHOULD only be used where changing 3109 conditions mandate superseding previous Events. 3110 3111
8) When changing conditions mandate changes in the sequence or contents of Events, the 3112 following guidelines MAY be used to indicate desired actions: 3113
a. Canceling existing Events and reissuing new Events. 3114 b. Sending overlapping or nested Events to supersede existing Events. 3115
3116 9) When a Nested Event completes the containing / superseded Event SHALL NOT be reinstated 3117
and remain in a superseded state. 3118 3119
10) For function sets with direct control, it is RECOMMENDED that process 8.b be used for most 3120 situations since it can allow a smoother change between two sets of directives but in no way 3121 does it negate the responsibilities identified in rule #7. 3122 3123
11) Clients SHALL verify the EventStatus of an Event before acting upon it. If the EventStatus 3124 potentiallySupercededTime has changed since last checked, and if the EventStatus type is 3125 "Partially Superseded", clients SHALL check all Events from that function set instance that may 3126 supersede the original Event. 3127 3128
12) When a client receives an Event with the Specified End Time in the past (Specified End Time < 3129 Current Time), this Event SHALL be ignored. Note that the Duration Randomization is not used 3130 in this calculation. 3131
a. For function sets with direct control, if the Event responseRequired indicates, clients 3132 SHALL POST a Response to the replyTo URI with a Status of "Rejected - Event was 3133 received after it had expired". 3134 3135
13) When a client receives an Event and calculates an Effective Start Time (Start Time + Start 3136 Randomization) in the past and a Specified End Time in the future ((Effective Start Time < 3137 Current Time) AND (Specified End Time > Current Time)), the client SHALL begin the Event 3138 using the current time and the absolute value of Start Randomization. For response reporting 3139 purposes, the start time SHALL be reported as the Current Time plus applied Start 3140 Randomization applied. For Event duration purposes, the Specified End Time SHALL be 3141 preserved, and any Duration Randomization attributes SHALL be applied to the abbreviated 3142 Duration. 3143 3144
14) For function sets with direct control, regardless of the state of an Event (scheduled or active), 3145 when a client detects an Overlapping Event condition, the Event with the latest creation time 3146 will take precedence over the previous Event. Depending on the state of the Event (scheduled or 3147 active), one of the following steps SHALL take place: 3148
a. If the previous Event is scheduled and not active and if the Event responseRequired 3149 indicates, the client SHALL POST a Response (referencing the previous Event) with the 3150 Status of "The Event has been superseded." After the Response has been successfully 3151 POSTed, the client SHALL ignore the previous Event scheduled. 3152
b. If the previous Event is active, the client SHALL change directly from its current state 3153 to the requested state at the effective start time of the Overlapping Event. If the Event 3154 responseRequired indicates, the client SHALL POST a response (referencing the 3155 previous Event) with a Status of 'The event has been superseded' at the effective start 3156 time of the Overlapping Event. 3157
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 99 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
3158 15) Randomization SHALL NOT cause Event conflicts or unmanaged gaps. To clarify: 3159
a. For Successive Events clients SHALL use the earlier Event 's Effective End Time as the 3160 Effective Start Time of the later Event. Events are not reported as superseded and Clients 3161 should report Event statuses as they normally would for a set of Successive Events. 3162 Note: This means that a group of Successive Events without Duration Randomization 3163 will run successively using the initial Start Randomization for each of the Events in the 3164 group. 3165
b. Randomization SHALL NOT artificially create a gap between Successive Events. 3166 3167
16) It is permissible to have gaps when Events are not Successive Events or Overlapping Events. 3168 3169
17) If multiple EndDeviceCategoryTypes are identified for an Event, future Events for an individual 3170 EndDeviceCategoryType (or a subset of the original Event) that cause an Overlapping Event 3171 will supersede the original Event strictly for that EndDeviceCategoryType (or a subset of the 3172 original Event). Note: Rule #6 applies to all Overlapping Events. 3173
a. Those clients whose EndDeviceCategoryType is not listed in the future Event but whose 3174 EndDeviceCategoryType was included in the original Event SHALL continue to 3175 execute per the parameters of the original Event. 3176
b. Rule #3 continues to apply. Servers SHALL NOT edit the original Event but SHALL 3177 maintain all Events in their entirety. 3178
c. A server SHALL set the potentiallySuperseded flag when the Event is superseded for 3179 any of the device categories and update the potentiallySupersededTime. 3180 3181
18) Servers SHOULD maintain and serve Events for the maximum Effective Scheduled Period. 3182 This applies even if the Event in question is cancelled, so as to support devices that may have 3183 previously received a copy of the Event from the server. 3184 3185
19) When an Event is removed from the server (e.g., due to limited storage space for the Event list) 3186 clients SHALL NOT assume the Event has been cancelled. Client devices SHALL only act on a 3187 cancellation as indicated in the rules above or an update to the Event's Status attribute. 3188
12.1.4 Randomization 3189
12.1.4.1 Overview 3190
The primary goal of randomization is to mitigate the effect of simultaneous actions by large groups of 3191 devices on distribution infrastructure (e.g., in response to a control signal). Adverse effects include 3192 voltage surges or sags, which can ripple through the distribution infrastructure and cause serious 3193 reliability problems or damage to electronic devices. Randomization is also useful to the orderly 3194 shutdown of operations prior to an event taking place to ensure the desired response occurs at the 3195 desired time. Use of randomization is appropriate and necessary to ensure the reliable and orderly 3196 operation of commodity distribution infrastructure. 3197
The randomization mechanism is suitable for any function set that signals devices to change behavior or 3198 causes actions to be taken in response. It is intended as a common object for all function sets. The 3199 primary function sets that use randomization are DRLC and Pricing. The DER function set may also 3200 make use of randomization. 3201
12.1.4.2 Randomization Attributes 3202
Randomization consists of two signed attributes: randomizeStart and randomizeDuration. Neither, one, 3203 or both of these may be included as part of an Event. 3204
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 100 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Randomization is implemented using signed integer(s) to indicate whether a HAN device executes a 3205 control action before or after the start or duration (or both start and duration) of the related Event. Time 3206 granularity for randomization is one second. 3207
The randomization values (randomizeStart and randomizeDuration) are generated by the creator of the 3208 Event. Clients acting on these Events use these values as bounds for generating a local random offset to 3209 the start and duration times, respectively, according to rules given below. Any device handling these 3210 Events and not operating on them SHALL NOT modify or apply them. 3211
Examples of how to set the randomization parameters to accomplish different load management 3212 techniques can be found in Section 16.20. 3213
12.1.4.2.1 randomizeStart 3214
The randomizeStart attribute represents the bound on the number of seconds to be used when 3215 randomizing the commencement of an Event. The device SHALL randomly select a number in seconds 3216 from zero to the randomizeStart specified for this event. Depending on the sign of the value (positive or 3217 negative), randomization SHALL be applied before or after the scheduled Start Time of the Event. If the 3218 value is negative, randomization SHALL be applied before the specified Start Time of the Event. 3219
For example, if an Event is scheduled to start at 11:00AM and has a randomizeStart value of "-300" 3220 (e.g., five minutes prior randomization), a client could randomly generate a number of "-120" (e.g., two 3221 minutes prior randomization) and begin the Event at 10:58AM. If the value is positive, randomization 3222 SHALL be applied after the specified Start Time of the event, causing the device to delay 3223 commencement of the Event. 3224
12.1.4.2.2 randomizeDuration 3225
The randomizeDuration represents the bound on the number of seconds to be used when randomizing 3226 the Duration of an Event. Devices SHALL randomly select a number in seconds from zero to the 3227 randomizeDuration value specified for the Event. Depending on the sign of the value (positive or 3228 negative), randomization SHALL be applied to increase or decrease the Duration of the Event. If the 3229 value is negative, randomization SHALL decrease the EffectiveDuration of the Event. 3230
For example, if an Event is scheduled to conclude at 1:00PM and has a randomizeDuration value of 3231 "-180", a client can select to end the Event at 12:59PM, indicating a negative 1 minute randomization. If 3232 the value is positive, randomization SHALL be added to the Duration of the Event, causing the device to 3233 delay termination of the Event. 3234
12.1.4.3 Application Guidelines / Behavior 3235
The values required to implement randomization represent relative time in seconds. Therefore, the 3236 signed values can be used to effect either positive or negative (relative to start time / duration) 3237 randomization. Clients that use fixed pseudo random values SHALL scale the applied randomization 3238 based on the range indicated by the given randomizeStart or randomizeDuration. Stated differently, 3239 fixed pseudo random values SHALL indicate a percentage of the randomizeStart or randomizeDuration 3240 to be applied. Fixed pseudo randomization is when a given device has a value that is applied for all 3241 randomizations. Manufacturers SHALL assure that fixed pseudo randomization values are random over 3242 a population of like devices. 3243
Clients that act upon Events SHALL support randomization. Clients SHALL apply randomization 3244 attributes when present in an Event's attributes. Absence of a randomizeStart or randomizeDuration 3245 value in an Event indicates randomization is not to be applied to the commencement or duration of an 3246 Event, respectively. 3247
Cancellation of an active Event SHALL cause clients to apply the greater of (absolute value of 3248 randomizeStart attribute) and (absolute value of randomizeDuration) to the abbreviated Event. 3249
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 101 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
If an Event is in progress and user override occurs, the client SHALL respond to the user override 3250 without randomization. 3251
12.1.5 Multi-Server 3252
12.1.5.1 Overview 3253
This section gives a description of how server and client devices should interact at the application layer 3254 when there are multiple servers of the same function set in the network, particularly in scenarios where 3255 there are multiple servers of a function set for the same commodity. There are several situations where 3256 this may occur; in some situations, one or more of the HAN's servers may be coordinated beyond the 3257 HAN, but this is not required. These guidelines provide methods and guidelines to facilitate orderly and 3258 predictable operations. 3259
12.1.5.2 Registration 3260
One key element in a multiple server network is the registration of devices to function set servers. 3261 Devices need the capability of determining which function set servers in the network it should receive 3262 data from and act upon for a particular commodity per function set. Devices MUST complete the 3263 registration and service discovery process for each of the function set servers with which the user 3264 intends it to access information. See the Security, Function Set Assignments and Service Discovery 3265 sections for more details. 3266
There may also be function set servers the device discovers with which it is not registered, or the 3267 function set server does not allow devices to register. In this case, the function set server MAY provide 3268 "public" information (e.g., provided without explicit registration by the user) that devices MAY receive. 3269 Depending on the specific function set guidelines, this may also factor into the application guidelines for 3270 multiple function set server scenarios. 3271
12.1.5.3 Time 3272
Time coordination is an important aspect of multiple server scenarios. Each function set server that has a 3273 reference to time SHALL also serve its respective time to the HAN. Clients SHALL choose a primary 3274 time server in the HAN with which to align its internal time per the Time function set guidelines. See 3275 the Time Function Set section (Section 11.1) for guidelines on dealing with multiple time servers in the 3276 network. 3277
12.1.5.4 Messaging Function Set 3278
Devices can obtain text messages from many servers, service providers, and / or other devices. It MAY 3279 be very common to have multiple messaging servers in a HAN. For details of managing multiple 3280 messaging servers see the Messaging section 12.5. 3281
12.1.5.5 Pricing Function Set 3282
Devices MAY obtain pricing data from many servers, service providers, and / or other devices. It may 3283 be very common to have multiple Pricing servers in a HAN. For details of managing multiple Pricing 3284 servers see the Pricing section 12.4. 3285
12.1.5.6 DRLC and DER Control Function 3286
There may be multiple DRLC and / or DER function set instances in a HAN, each operating 3287 independently. With the ability to act on instances from multiple servers that may not be coordinated in 3288 any way, there is the opportunity for conflicting / overlapping Events within a function set that the client 3289 will need to handle. Clients SHALL only report acting on one Event at a time and SHALL NOT respond 3290 to multiple DRLC or DER servers that they are acting on multiple Events for that function set 3291 simultaneously. If clients are getting Events from multiple servers of the same function set they SHALL 3292 detect duplicate Events by comparing the mRIDs of the Events. If a duplicate is detected the client MAY 3293 respond to either, but, if requested, one response is REQUIRED. 3294
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 102 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
When devices are registered to one or more DRLC servers, they SHALL NOT act upon any public 3295 DRLC servers that are present in the HAN or become available. 3296
When devices are registered to one or more DER Control servers, they SHALL NOT act upon any 3297 public DER Control servers that are present in the HAN or become available. 3298
Clients SHALL determine the primacy of DRLC and DER Control based on the following in order of 3299 precedence: 3300
1) Servers SHALL indicate their primacy in the primacy element of the function set instance. See 3301 schema [ZB 13-0201] definition of PrimacyType for possible values. 3302
2) Clients SHALL prioritize execution of DRLC and DER function set Events with different 3303 PrimacyType attributes using the following guidelines: 3304
o 0 supersedes 1 3305
o 1 supersedes 2 3306
o 2 supersedes 3 3307
o If two instances are received with the same priority, then normal Event Rules and 3308 Guidelines apply (e.g., superseding based on scheduling). 3309
3) If a client is executing an Event from one server and decides to execute an Event from a 3310 different server per the application guidelines and if the superseded Event responseRequired 3311 indicates, the client SHALL send a response with "Aborted due to an Alternate Provider Event" 3312 Response.status for the Event that was superseded. 3313
This mechanism and these guidelines allow service providers to coordinate amongst themselves or for 3314 regulatory / legislative entities to enforce coordination. Reputable service providers should appropriately 3315 self-select their PrimacyType attribute so as not to disadvantage the consumer's participation in their 3316 contracted DR or DER Control service providers programs. This method does not prevent non-reputable 3317 providers from misrepresenting their communications. 3318
12.2 Demand Response and Load Control 3319
12.2.1 Overview 3320
This function set provides an interface for Demand Response and Load Control (DRLC). Client devices 3321 of this function set include thermostats and devices that support load control. Server devices of this 3322 function set include ESIs, premises energy management systems that may be acting as a proxy for 3323 upstream demand response / load control management systems and subsequent data stores. 3324 Servers expose load control events to client devices through resources called "EndDeviceControls" 3325 (EDC). All EDC instances expose attributes that allow devices to respond to events that are explicitly 3326 targeted at their device type. For example, an EDC may contain an Offset object indicating a degree 3327 offset to be applied by a Smart Thermostat. The EDC will also expose necessary attributes that load 3328 control client devices will need in order to process an event. These include Start Time and Duration, as 3329 well as an indication on the need for randomization of the start time or duration of the event. 3330
12.2.2 List Ordering 3331 Table 12-1 Demand Response and Load Control List Ordering. 3332
Resource Name Primary Key Secondary Key Tertiary Key
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 103 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Resource Name Primary Key Secondary Key Tertiary Key
DemandResponseProgram Primacy (ascending)
mRID (descending)
NA
EndDeviceControl and ActiveEndDeviceControl
interval.start (ascending)
creationTime (descending)
mRID (descending)
12.2.3 Application Guidelines / Behavior 3333
12.2.3.1 DemandResponseProgram 3334
Multiple programs can be created to target different types of devices or to offer different types of 3335 incentives. DemandResponseProgram SHALL use mRID as a unique identifier for each instance of a 3336 program. 3337
DemandResponseProgram server devices SHALL be capable of internally storing and supporting at 3338 least 1 DemandResponseProgram instance. DemandResponseProgram server devices SHOULD be 3339 capable of internally sorting and supporting 3 unique DemandResponseProgram instances. 3340
DemandResponseProgram client devices SHALL be capable of internally storing and supporting at least 3341 1 DemandResponseProgram instance. DemandResponseProgram client devices SHOULD be capable of 3342 internally storing and supporting 3 unique DemandResponseProgram instances. 3343
12.2.3.2 EndDeviceControl 3344
An EndDeviceControl is used to provide control parameters to a DRLC client. An EndDeviceControl 3345 can always be overridden by the user. 3346
Demand Response / Load Control server devices SHALL be capable of internally storing and supporting 3347 at least 5 unique EndDeviceControl instances that MAY be distributed between multiple programs. 3348 Demand Response / Load Control server devices SHOULD be capable of internally storing and 3349 supporting at least of 10 unique EndDeviceControl instances. 3350
Demand Response / Load Control client devices SHALL be capable of internally storing and supporting 3351 at least 3 unique EndDeviceControl instances. Demand Response / Load Control client devices 3352 SHOULD be capable of internally storing and supporting at least 5 unique EndDeviceControl instances. 3353 As a highly RECOMMENDED recovery mechanism, when a maximum of storage of events has been 3354 reached and additional EndDeviceControl instances are available on the server(s), clients SHOULD 3355 prioritize local storage and give preference to EndDeviceControls with start times in the near future and 3356 to events that have been flagged as mandatory. 3357
12.2.3.3 Rules and Guidelines 3358
Note that the rules and guidelines detailed below apply to DRLC client devices that change their 3359 consumption behavior based on the demand response signals received. Display only DRLC client 3360 devices are not required to comply with the normative statements presented below. 3361
If an EndDeviceControl includes more than one control parameter, the DRLC client is free to utilize 3362 applicable parameters of its choice. If the DRLC client is capable of supporting multiple parameters 3363 from the ones that have been included in the event, it SHOULD select the parameter that best fits its 3364 functionality. 3365
12.2.3.3.1 availabilityUpdateChangePercentThreshold/ availabilityUpdateChangePowerThreshold 3366
When Demand Response / Load Control servers support the LoadShedAvailability resource, they 3367 SHALL use either the availabilityUpdateChangePercentThreshold or 3368 availabilityUpdateChangePowerThreshold to indicate the threshold for which a client is required to 3369 update its current load shed ability. The availabilityUpdateChangePercentThreshold is used to indicate a 3370
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 104 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
percent change in load shed availability that SHALL trigger an update from the client. The 3371 availabilityUpdateChangePowerThreshold is used to indicate an absolute change in available load shed 3372 capability that SHALL trigger an update from the client. If no 3373 availabilityUpdateChangePercentThreshold or availabilityUpdateChangePowerThreshold is specified 3374 then clients SHALL NOT POST to their LoadShedAvailability for that program. If the server provides 3375 both, the client SHALL update its current load shed availability when either threshold is crossed. 3376
12.2.3.3.2 drProgramMandatory 3377
Events flagged as drProgramMandatory are strongly RECOMMENDED to be acted upon. 3378
If a user attempts to opt-out of an EndDeviceControl with the drProgramMandatory flag set, clients 3379 SHALL require an extra acknowledgment from the user confirming the desire to opt-out. Client devices 3380 MAY allow the user to opt out of EndDeviceControls even if the drProgramMandatory flag is true for 3381 the given event. Clients SHOULD present a warning to indicate that this event has been flagged as 3382 mandatory by their service provider. For example, the client can present a screen stating that "Utility X 3383 has marked this event as mandatory and an opt-out can lead to financial penalties as agreed upon in the 3384 contract with Utility X." 3385
12.2.3.3.3 overrideDuration 3386
After the overideDuration time of an EndDeviceControl has elapsed, the client device SHALL return to 3387 execution of the EndDeviceControl for the remaining Effective Scheduled Period. 3388
Client devices MAY allow users to override an EndDeviceControl for a longer duration than event 3389 overrideDuration, in which case they SHOULD provide a warning for non-compliance if the 3390 drProgramMandatory flag is set to true. 3391
12.2.3.3.4 DateTimeInterval 3392
The duration of the EndDeviceControl is provided in seconds using the duration attribute. Events 3393 SHALL NOT be longer than 86,400 seconds (1 day). 3394
12.2.3.3.5 SetPoint 3395
When both a Temperature Offset and a Temperature Set Point are provided, the device MAY use either 3396 as defined by the device manufacturer. 3397
In some cases an EDC MAY include an Offset or Set Point that will cause the device to increase its 3398 energy consumption. This may be done as a form of pre-heating or pre-cooling before an event that 3399 reduces consumption is dispatched. This type of EDC SHALL set the loadShiftForward flag to "True". 3400
12.2.3.4 Response 3401
When overriding an event, client devices SHOULD provide a duration for the override using the 3402 drOverrideDuration attribute found in the DrResponse object. This is useful for service providers and 3403 EMS in understanding for how long the client device will override the event and when it can expect the 3404 client device to return to shedding load. 3405
Additional guidelines on how the Response resource operates are provided in the Response Function Set 3406 in Section 10.7. 3407
12.2.3.5 LoadShedAvailability 3408
When clients support the LoadShedAvailability resource they SHALL POST their ability to shed load 3409 when first connected to a server that supports the resource. If the commitment is related to a program, 3410 the client SHALL provide a link to the specific DemandResponseProgram. Clients SHALL update their 3411 availability based on the update thresholds provided by the program where the load shed is being 3412 committed. If no thresholds are specified by the server, then clients SHALL NOT POST updates to their 3413 LoadShedAvailability for the provider of that program. 3414
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 105 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Clients reporting their LoadShedAvailability to multiple DemandResposePrograms SHALL be capable 3415 of individually providing the committed power or percentage to each program for a reported duration. 3416 For example, a client capable of shedding 2kW load SHALL NOT report 2kW of availability to two 3417 separate programs, instead it SHALL divide its availability between the two. Client devices already 3418 shedding load and reporting on additional availability, SHALL be aware of their current state of 3419 consumption, as any new event requiring energy reduction SHALL be applied to the device's current 3420 baseline of consumption. 3421
12.2.4 LogEvents 3422
There are no LogEvents generated by this function set. 3423
12.3 Metering Function Set 3424
12.3.1 Overview 3425
The Metering function set provides interfaces to exchange commodity measurement information such as 3426 reading types and meter readings between HAN devices. Examples of Meter Flows and XML payloads 3427 are listed in Appendix C. 3428
Each Metering function set server may have a UsagePointList resource containing resources for local 3429 meters and metering data mirrored for other devices. One possible scenario is that two electric meters 3430 exist in a HAN. Both have a UsagePoint resource. Electric Meter #1 (e.g., ESI integrated) has a 3431 UsagePoint list which contains for example /upt/0 (meter itself) and /upt/1 (mirrored gas meter). Electric 3432 Meter #2 also has ESI integrated and has for example a /upt list which contains only one instance /upt/0 3433 (meter itself) but no other meter mirrored to it. Since both UsagePoints are visible, a HAN device that 3434 does service discovery will find both UsagePoint servers and it then has to decide which UsagePoint 3435 server to query based on server's information. Note that although there are two /upt/0 instances in this 3436 case, they are two different servers with different hostnames and / or IP addresses. 3437
12.3.2 List Ordering 3438 Table 12-2 Metering List Ordering. 3439
Resource Name Primary Key Secondary Key Tertiary Key
UsagePoint mRID (descending)
NA NA
MeterReading mRID (descending)
NA NA
ReadingSet timePeriod.start (descending)
mRID (descending)
NA
Reading localID (ascending)
consumptionBlock (ascending)
touTier (ascending)
12.3.3 Application Guidelines / Behavior 3440
The Metering function set resource hierarchy starts with a list of Usage Points. A Usage Point is an 3441 abstraction for a point of exchange. This could be represented as a physical meter or a fixed load like a 3442 street lamp or a virtual metering point as accomplished with transformer or line loss compensation 3443 algorithms. Each Usage Point then has one or more Meter Readings. Meter Readings serve as an 3444 aggregation for the ReadingType, a possible Reading and possible Reading Sets. The ReadingType is 3445 constructed based on subsets and extensions of IEC 61968-9 Annex C – Reading Types [61968]. Only 3446 relevant IEC fields are listed in the XML schema described in [ZB 13-0201] and SEP 2 UML model. It 3447 may be beneficial for implementers to obtain a copy of this IEC document in order to better understand 3448
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 106 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
the meanings and uses of the IEC 61968-9 Reading Types [61968]. See the following text for uses of the 3449 ReadingSets and Readings. 3450
In the following text, the terms "current" and "present" refer to the values at the time the resource is 3451 read. In terms of ReadingSets the terms refer to the ReadingSet that is being built / filled at the time of 3452 reading. While a ReadingSet is in this state, ReadingSet.timePeriod.start SHALL be when the 3453 ReadingSet starts recording its first value and that ReadingSet.timePeriod.duration SHALL grow each 3454 time the ReadingSet is updated. The ReadingSet.mRID field SHALL be assigned a value of 3455 0xFFFFFFFFFFFFFFFFFFFFFFFF[XXXXXXXX] (Where [XXXXXXXX] is replaced by the 3456 manufacturer's PEN) while the data is being recorded and changed to an appropriate mRID when the 3457 ReadingSet is complete. 3458
A Metering function set instance that provides instantaneous demand data SHALL serve a Meter 3459 Reading resource (and subordinate resources) with the following properties: 3460
� SHALL contain a ReadingTypeLink element that points to a ReadingType resource that 3461 matches the InstantaneousDemand definition from Table 12-3. 3462
� SHALL contain a ReadingLink element that points to a Reading resource that contains the 3463 instantaneous demand value. 3464
� SHALL NOT contain a ReadingSetListLink element. 3465
A Metering function set instance that provides summation delivered data SHALL serve a Meter Reading 3466 resource (and subordinate resources) with the following properties: 3467
� SHALL contain a ReadingTypeLink element that points to a ReadingType resource that 3468 matches the SummationDelivered definition from Table 12-3. 3469
o The ReadingType resource SHALL specify the number of TOU tiers and / or 3470 consumption blocks, if any, that the metering instance provides. 3471
� SHALL contain a ReadingSetListLink element that points to a ReadingSetList resource. 3472 o When metering data is present, the ReadingSetList SHALL contain at least one 3473
ReadingSet resource, which corresponds to the present summation delivered data. 3474 � The ReadingSet resource SHALL contain a ReadingListLink element that 3475
points to a ReadingList resource. The ReadingList resource SHALL contain 3476 (number of TOU tiers + 1) multiplied by (number of consumption blocks + 1) 3477 Reading resources. 3478
� The Reading resources in the ReadingList SHALL correspond to the summation 3479 delivered value for each combination of consumptionBlock=0..(number of 3480 consumption blocks) and touTier=0..(number of TOU tiers). 3481
� The Reading for (consumptionBlock=0, touTier=0) SHALL correspond to the 3482 total summation delivered. 3483
� The Reading for (consumptionBlock=x >0, touTier=0) SHALL correspond to 3484 the Block x summation delivered (across all TOU tiers). 3485
� The Reading for (consumptionBlock=0, touTier=y >0) SHALL correspond to 3486 the TOU Tier y summation delivered (across all consumption blocks). 3487
� The Reading for (consumptionBlock=x > 0, touTier=y >0) SHALL correspond 3488 to the consumptionBlock x, touTier y summation delivered. 3489
� SHALL contain a ReadingLink to a Reading resource that contains the present summation 3490 delivered, which is semantically equivalent to the Reading for (consumptionBlock=0, 3491 touTier=0) for the present ReadingList. 3492
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 107 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
A Metering function set instance that provides summation received data, maximum demand delivered 3493 data, maximum demand received data, and / or other reading type data that utilizes TOU tiers and / or 3494 consumption blocks SHALL serve a Meter Reading resource (and subordinate resources) as per the 3495 rules for Summation Delivered above, but with the ReadingType resource matching the appropriate 3496 definition in Table 12-3, and with the Reading values corresponding to the appropriate data type. 3497
A Metering function set instance that provides interval data SHALL serve a Meter Reading resource 3498 (and subordinate resources) with the following properties: 3499
� SHALL contain a ReadingTypeLink element that points to a ReadingType resource that 3500 matches an Interval data definition from Table 12-3. 3501
o The The ReadingType resource SHALL specify the intervalLength that is the default for 3502 the intervals contained in the ReadingList resource. 3503
� SHALL contain a ReadingSetListLink element that points to a ReadingSetList resource. 3504 o When metering data is present, the ReadingSetList SHALL contain at least one 3505
ReadingSet resource, which corresponds to the present Interval Block data (the one 3506 currently being filled). 3507
� The ReadingSet resource SHALL contain a ReadingListLink element that 3508 points to a ReadingList resource. The ReadingList resource SHALL contain 3509 Reading resources each of which represents a portion (interval) of the 3510 timePeriod of the ReadingSet. 3511
� If the duration in the Time Period of the Reading is not equal to the 3512 intervalLength specified in the ReadingType the timePeriod SHALL be 3513 included in the Reading. 3514
� SHALL NOT contain a ReadingLink resource. 3515
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 108 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
The following table provides a list of common Reading Type Definitions with related fields listed. 3516
Table 12-3 Reading Types. 3517
Rea
ding
Typ
e E
lem
ent
accu
mul
atio
nBeh
avio
ur
calo
rific
Val
ue
com
mod
ity
conv
ersi
onFa
ctor
data
Qua
lifie
r
flow
Dir
ectio
n
inte
rval
Len
gth
kind
num
berO
fCon
sum
ptio
nBlo
cks
num
berO
f Tou
Tie
rs
phas
e
pow
erO
fTen
Mul
tiplie
r
subI
nter
valL
engt
h
supp
yLim
it
tiere
dCon
sum
ptio
nBlo
cks
uom
ReadingType Name
Instantaneous Demand
12 1 1 E 8 O E E 38
Summation Delivered 9 1 1 E 12 O O O E 72
Summation Received 9 1 19 E 12 O O O E 72
Max Demand Delivered 6 1 8 1 O 8 O O O E 38
Max Demand Received 6 1 8 19 O 8 O O O E 38
Intervals Delivered 4 1 1 O 12 O E E 72
Intervals Received 4 1 19 O 12 O E E 72
Blank cells indicate not used for the given ReadingType Name. May be used for other ReadingTypes.
"E" cells indicate SHALL NOT be used for this class of ReadingType no matter commodity.
"O" cells indicate there MAY be value specified.
Note the values in this table, are provided as examples of possible electricity meter ReadingTypes. A metering instance must set these values as appropriate for its commodities. For example, SummationDelivered may apply to gas or water if the commodity is "NaturalGas" with uom value of 42(m3) or "PotableWater" with uom value of 128(US gl) or 134 (liters). Other commodities SHALL indicate appropriate UOMs. A combination of uom and powerOfTenMultiplier are used to represent units with different magnitudes, for example kWh would be represented as uom of 72 and a powerOfTenMultiplier of 3. As for fractional Wh readings, 0.012 Wh can be expressed as powerOfTenMultiplier = -3 & uom = 72 and value=12.
Relevant UOMs and other reading type fields are listed in the XML schema described in [ZB 13-0201].
3518
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 109 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
12.3.4 LogEvents 3519
This subsection includes definitions of all LogEvents that may be raised by the metering function set. 3520 The LogEvent names and codes are summarized in the table below. 3521
Table 12-4 Metering LogEvents. 3522
LogEvent Name LogEvent Code LogEvent Description
UPT_CHECK_METER 0x00 SHOULD be issued when check meter alarm occurs
UPT_TAMPER_DETECT 0x01 SHOULD be issued when a tampering is detected
UPT_POWER_QUALITY 0x02 SHOULD be issued when power quality alarm occurs. It is a generic power quality event code
UPT_ LEAK_DETECT 0x03 SHOULD be issued when a leak is detected
UPT_SERVICE_DISCONNECT 0x04 SHOULD be issued when service is disconnected
UPT_SERVICE_LIMITED 0x05 SHOULD be issued when service limited alarm occurs
UPT_LOW_VOLTAGE_L1 0x06 SHOULD be issued when low voltage L1 occurs
UPT_HIGH_VOLTAGE_L1 0x07 SHOULD be issued when high voltage L1 occurs
UPT_LOW_VOLTAGE_L2 0x08 SHOULD be issued when low voltage L2 occurs
UPT_HIGH_VOLTAGE_L2 0x09 SHOULD be issued when high voltage L2 occurs
UPT_LOW_VOLTAGE_L3 0x0A SHOULD be issued when low voltage L3 occurs
UPT_HIGH_VOLTAGE_L3 0x0B SHOULD be issued when high voltage L3 occurs
UPT_OVER_CURRENT_L1 0x0C SHOULD be issued when over current L1 occurs
UPT_OVER_CURRENT_L2 0x0D SHOULD be issued when over current L2 occurs
UPT_OVER_CURRENT_L3 0x0E SHOULD be issued when over current L3 occurs
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 110 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
LogEvent Name LogEvent Code LogEvent Description
UPT_FREQUENCY_TOO_LOW_L1 0x0F SHOULD be issued when frequency too low L1
UPT_FREQUENCY_TOO_HIGH_L1 0x10 SHOULD be issued when frequency too high L1
UPT_FREQUENCY_TOO_LOW_L2 0x11 SHOULD be issued when frequency too low L2
UPT_FREQUENCY_TOO_HIGH_L2 0x12 SHOULD be issued when frequency too high L2
UPT_FREQUENCY_TOO_LOW_L3 0x13 SHOULD be issued when frequency too low L3
UPT_FREQUENCY_TOO_HIGH_L3 0x14 SHOULD be issued when frequency too high L3
UPT_GROUND_FAULT 0x15 SHOULD be issued when ground fault occurs
UPT_BURST_DETECT 0x16 SHOULD be issued when burst detect alarm occurs
UPT_PRESSURE_TOO_LOW 0x17 SHOULD be issued when pressure too low
UPT_PRESSURE_TOO_HIGH 0x08 SHOULD be issued when pressure too high
UPT_FLOW_SENSOR_COMMUNICATION_ERROR 0x19 SHOULD be issued when flow sensor communication error occurs
UPT_FLOW_SENSOR_MEASUREMENT_FAULT 0x1A SHOULD be issued when flow sensor measurement fault occurs
UPT_FLOW_SENSOR_REVERSE_FLOW 0x1B SHOULD be issued when reverse flow is detected
UPT_FLOW_SENSOR_AIR_DETECT 0x1C SHOULD be issued when flow sensor air detect alarm occurs
UPT_PIPE_EMPTY 0x1D SHOULD be issued when pipe empty alarm occurs
UPT_INLET_TEMPERATURE_SENSOR_FAULT 0x1E SHOULD be issued when inlet temperature sensor fault
UPT_OUTLET_TEMPERATURE_SENSOR_FAULT 0x1F SHOULD be issued when outlet temperature sensor fault
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 111 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
12.4 Pricing Function Set 3523
12.4.1 Overview 3524
The pricing function set provides the tariff structures communicated by the server and is designed to 3525 support a variety of tariff types, including: 3526
� Flat-rate pricing 3527
� Time-of-Use tiers 3528
� Consumption blocks 3529
� Hourly day-ahead pricing 3530
� Real-time pricing 3531
� Combinations of the above 3532
The Pricing Function Set supports application-specific tariffs for devices (e.g., PEV, DER), and special 3533 event-based prices like critical peak price (Note, as per [ZB 13-0201], CPP is treated as just another TOU 3534 tier). 3535
The Pricing Function Set is designed to stand on its own but can be paired with the Metering, Billing and 3536 Prepayment function sets to provide additional benefit to users. The Pricing Function Set is not intended 3537 to provide all the information necessary to represent a premises's bill. 3538
12.4.2 List Ordering 3539 Table 12-5 Pricing List Ordering. 3540
Resource Name Primary Key Secondary Key Tertiary Key
TariffProfile mRID (descending)
NA NA
RateComponent mRID (descending)
NA NA
TimeTariffInterval and ActiveTimeTariffInterval
interval.start (ascending)
creationTime (descending)
mRID (descending)
ConsumptionTariffInterval startValue (ascending)
NA NA
12.4.3 Application Guidelines / Behavior 3541
12.4.3.1 TariffProfile 3542
Pricing servers SHALL be capable of internally storing and supporting at least one TariffProfile instance. 3543
Pricing clients SHALL be capable of internally storing and supporting at least one TariffProfile instance. 3544
Pricing servers SHOULD be capable of internally storing and supporting at least three TariffProfile 3545 instances (e.g., multiple commodities, multiple service provider tariff options). 3546
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 112 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Pricing clients SHOULD be capable of internally storing and supporting at least three TariffProfile 3547 instances (e.g., multiple commodities, multiple service provider tariff options). 3548
12.4.3.2 Rate Component 3549
Pricing servers SHALL support at least two RateComponent instances for each TariffProfile. 3550
Pricing clients SHALL support at least one RateComponent instance for each TariffProfile. Pricing 3551 clients supporting the use of this resource SHOULD support at least two instances of RateComponent 3552 (e.g., to convey prices for forward energy [consumed by premises] and reverse energy [supplied by 3553 premises]). 3554
12.4.3.3 TimeTariffInterval 3555
Rates that do not contain time-differentiated characteristics SHALL create one TimeTariffInterval 3556 instance with a DateTimeInterval of sufficient duration to cover at least the next 24 hours or use the 3557 maximum time value for duration to minimize data transmission. 3558
Pricing servers SHALL support at least two TimeTariffInterval instances per RateComponent instance 3559 (e.g., the active and subsequent TimeTariffInterval instance for a RateComponent). 3560
Pricing servers SHOULD support at least 48 TimeTariffInterval instances for at least one RateComponent 3561 instance. 3562
Pricing servers SHALL provide at most one active TimeTariffInterval per rate component. 3563 TimeTariffIntervals are to be scheduled for each occurence of a TOU. A given day would have a flow of 3564 TimeTariffIntervals for the TOU rates for that day. A particular TimeTariffInterval instance specifies the 3565 touTier that is in effect during that event's effective time period. 3566
Pricing clients, upon detecting multiple active TimeTariffIntervals, SHALL ignore all but the 3567 TimeTariffInterval with the highest creation time. If this is insufficient to determine a unique active 3568 TimeTariffInterval (e.g., two active instances exist with the same creation time), clients SHALL operate 3569 as if there is no TimeTariffInterval defined for the given time period. 3570
Pricing clients SHALL be capable of internally storing and supporting at least two TimeTariffInterval 3571 instances per RateComponent instance. 3572
Pricing clients SHOULD be capable of internally storing and supporting at least five TimeTariffInterval 3573 instances per RateComponent instance. 3574
The series of TimeTariffInterval instances on a server may contain gaps or breaks where pricing 3575 information is not defined for some time period. This may occur for various reasons, such as when private 3576 information is cleared from the server (e.g., during move-out) or potentially when superseding 3577 TimeTariffIntervals are created by the service provider (however, service providers should take care to 3578 ensure that gaps are not created, by creating additional TimeTariffInterval instances if necessary). The 3579 below guidelines promote common pricing client behavior and reduce the chances of different 3580 implementations displaying different cost information to a user in the event pricing information is 3581 unavailable during a particular period. This could cause users to question the reliability of the data. Rules 3582 for handling these gaps are as follows: 3583
� If a pricing client displays the active or scheduled price or calculated instantaneous cost data to 3584 the user, the client SHALL indicate the presence of an unexpected issue with the price data. 3585
� If a pricing client displays calculated running or averaged cost data to the user, the client MAY 3586 continue to display values by excluding the time periods where no price is defined. However, the 3587
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 113 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
client SHALL also indicate the presence of an unexpected issue with the price data for as long as 3588 there are price gaps during the time period the client uses to calculate these values. 3589
� Pricing clients SHALL NOT default to any hardcoded price attribute (e.g., $0) or use a price 3590 attribute from another (past / future) TimeTariffInterval for display or calculation. If a pricing 3591 client displays human-readable pricing information, then they SHALL display a non-numerical 3592 indicator (e.g., "XX", dashes, "NA"). 3593
� If the pricing server later makes TimeTariffInterval instances available to fill pricing gaps, 3594 pricing clients that display calculated cost information MAY recalculate past cost data based on 3595 the new information. 3596
Pricing clients that are price responsive SHOULD return to normal operational mode (that is, the default 3597 behavior of the device without any price responsiveness) during time periods where no 3598 TimeTariffInterval instance is defined. These clients SHOULD provide some notification to the user that 3599 the active TimeTariffInterval instance price information is unknown. 3600
The ActiveTimeTariffIntervalList only filters out inactive TimeTariffProfile instances; this SHALL NOT 3601 filter out ConsumptionTariffInterval instances. That is, if a client GETs a TimeTariffInterval from a 3602 server's ActiveTimeTariffIntervalList, the ConsumptionTariffIntervalList pointed to by that 3603 TimeTariffInterval's ConsumptionTariffIntervalListLink SHALL contain all ConsumptionTariffInterval 3604 instances (equal to the number of consumption blocks defined in the ReadingType), not just the one 3605 active ConsumptionTariffInterval instance. 3606
12.4.3.4 Interval 3607
While strongly RECOMMENDED, Pricing clients are NOT REQUIRED to follow the sign of 3608 randomization for Pricing function set messages. However, Pricing clients SHALL observe the absolute 3609 value of the randomizeDuration or randomizeStart value for the randomization range when calculating the 3610 randomization value. This allows more capable price clients to look ahead at scheduled prices (if 3611 available) and, using knowledge of the client's operating characteristics, determine if it is in the 3612 customer's best interest to react to the event earlier or later. 3613
If, while a price-responsive client is acting upon a TimeTariffInterval, that TimeTariffInterval is 3614 cancelled, the client SHALL observe the randomizeDuration value when ceasing action. 3615
12.4.3.5 ConsumptionTariffInterval 3616
Pricing servers SHALL be capable of internally storing and supporting at least one 3617 ConsumptionTariffInterval element per TimeTariffInterval instance. 3618
Pricing servers SHOULD be capable of internally storing and supporting at least five 3619 ConsumptionTariffInterval elements per TimeTariffInterval instance. 3620
Pricing clients SHOULD be capable of internally storing and supporting at least five 3621 ConsumptionTariffInterval elements per TimeTariffInterval instance. 3622
A particular TimeTariffInterval instances MAY NOT include a ConsumptionTariffIntervalListLink, 3623 meaning that ConsumptionTariffIntervals (and therefore the actual price) is not available for that 3624 TimeTariffInterval. In such a case, price responsive clients would be unable to act upon price; however, 3625 they MAY be price responsive to the touTier value (if present) in the TimeTariffInterval. 3626
12.4.3.6 Sleepy Devices / Polling Clients 3627
It is RECOMMENDED that sleepy pricing client devices send requests to the pricing server on a periodic 3628 basis. The RECOMMENDED time period for the periodic poll (for sleepy devices or other clients that do 3629 not or are unable to make use of subscriptions) is no more than once per hour but at least once per 24-3630
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 114 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
hour period. This ensures the client a high likelihood of receiving the pricing information needed to 3631 manage its operations in a timely fashion while respecting limited network resources. 3632
It is RECOMMENDED that polling pricing client devices request updated information for pending 3633 TimeTariffInterval instances just prior to those TimeTariffInterval instances becoming active (e.g., 5-10 3634 minutes prior, including any negative randomizeStart). This ensures the TimeTariffInterval instance 3635 previously retrieved is still valid and accurate with the latest instance on the server. 3636
12.4.3.7 Deployments with Multiple Pricing Servers 3637
For the purposes of price responsiveness, clients SHOULD only follow one pricing server in the HAN per 3638 commodity. Pricing clients MAY follow multiple Pricing servers for informational display purposes (e.g., 3639 to compare different providers) or price seeking behavior. More sophisticated devices (e.g., Premises 3640 Energy Management System) MAY follow multiple Pricing servers and make policy based decisions to 3641 dispatch local resources (e.g., Distributed Energy Resource) and / or provide a single Pricing server for 3642 clients it controls based on user preferences. 3643
Registered pricing devices SHALL determine their primary Pricing server via Function Set Assignments 3644 and follow it for the purposes of price responsiveness. It is incumbent upon the user to choose the Pricing 3645 server with which to register the device. Pricing devices SHALL periodically perform service discovery 3646 to find new pricing servers with which it is registered and begin following them for the purposes of price 3647 responsiveness. Pricing clients SHALL unsubscribe or discontinue following the previous Pricing server 3648 for the purposes of price responsiveness. In addition to periodic discovery of new Pricing servers, it is 3649 RECOMMENDED that devices allow a means of de-registration (or return to defaults) so the device can 3650 be manually de-registered and not require the periodic polling time. If a client is not registered to any 3651 Pricing server, the client SHALL use the Primacy value of any discovered public Pricing servers for the 3652 commodity or commodities of interest. 3653
When devices are registered to a Pricing server, they SHALL not act upon any "public" pricing servers 3654 that are present in the HAN or become available. 3655
12.4.3.8 Relative Pricing between Tiers and Blocks 3656
Pricing servers using multiple TOU tiers SHALL associate higher prices with higher touTier values. That 3657 is, the price of any (TOU Tier N, Consumption Block M) SHALL be less than or equal to the price of 3658 (TOU Tier N+1, Consumption Block M). Note that this is only valid for comparing the same 3659 consumptionBlock between two TOU tiers. Servers MAY be configured such that one or more 3660 consumptionBlock prices from TOU tier N are greater than one or more consumptionBlock prices from 3661 TOU tier N+1. 3662
Similarly, there is no restriction regarding the relative prices between consumptionBlock prices within the 3663 same TOU tier. That is, within one TOU tier, the price of consumptionBlock N MAY be greater than the 3664 price of consumptionBlock N+1. 3665
12.4.3.9 Price Responsiveness 3666
Servers that also support EndDevice instances MAY include price response thresholds for a particular end 3667 device. This provides a standard mechanism for end devices without user interfaces to receive 3668 configuration data concerning customer preferences for price responsiveness. Servers MAY provide a 3669 unique PriceResponseCfg resource for each RateComponent resource that server hosts. 3670
Pricing clients that are registered to a particular Pricing program and are acting upon a particular 3671 RateComponent SHOULD check their PriceResponseCfgList for a PriceResponseCfg resource 3672 corresponding to the RateComponent. If a matching PriceResponseCfg is present, pricing clients 3673
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 115 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
SHOULD consume the associated commodity when the price is less than the consumeThreshold value 3674 (typically used for scenarios such as negative pricing, pre-heating / cooling, and battery charging), and 3675 SHOULD reduce consumption to the maximum extent possible when the price is above the 3676 maxReductionThreshold value. 3677
If an appropriate PriceResponseCfg is not present, or the present price is between the consumeThreshold 3678 and maxReductionThreshold values, pricing clients MAY base responsiveness on comparing the active 3679 tier value to the total number of tiers as specified in the ReadingType (as per the price-tier relationship 3680 defined in Section 12.4.3.8). 3681
PriceResponseCfg servers SHALL NOT specify a consumeThreshold that is greater than or equal to the 3682 maxReductionThreshold. If a pricing client reads a PriceResponseCfg instance where the 3683 consumeThreshold is greater than or equal to the maxReductionThreshold, the client SHALL ignore the 3684 erroneous PriceResponseCfg instance. 3685
12.4.4 LogEvents 3686 Table 12-6 Pricing LogEvents. 3687
LogEvent Name LogEvent Code LogEvent Description
TP_NO_TTI 0x00 SHOULD be generated by a Pricing client when there is a gap between two TimeTariffInterval instances or if a TimeTariffInterval instance completes and is not followed by another.
12.5 Messaging Function Set 3688
12.5.1 Overview 3689
This function set provides an interface for a text messaging service. Client devices of this function set 3690 include In-Premises Displays and other text messaging display devices. Server devices of this function set 3691 include ESIs or a back office server, depending on system design. The response function set is used in 3692 conjunction with the messaging function set to allow client devices to confirm the viewing of messages 3693 and report advanced responses. 3694
Servers expose messages to client devices in the form of separate messaging URIs. Each messaging URI 3695 instance will contain information that a client device can use to display the message appropriately. For 3696 example, start time, duration of event, text to display, etc. 3697
12.5.2 List Ordering 3698
For list ordering purposes, the MessagingProgramList, TextMessageList and the ActiveTextMessageList 3699 SHALL be ordered based on the following criteria: 3700
Table 12-7 Messaging List Ordering. 3701
Resource Name Primary Key Secondary Key Tertiary Key
MessagingProgram mRID (descending)
NA NA
TextMessage and ActiveTextMessage
dateTimeInterval.start (ascending)
createdDateTime (descending)
mRID (descending)
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 116 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
12.5.3 Application Guidelines / Behavior 3702
12.5.3.1 Messaging Program 3703
MessagingProgram server and client devices SHALL be capable of internally storing and supporting at 3704 least 1 MessagingProgram instance. A MessagingProgram server and client device SHOULD be capable 3705 of supporting 3 unique MessagingProgram instances. 3706
12.5.3.2 Text Message 3707
MessagingProgram server devices SHALL be capable of internally storing and supporting at least 1 3708 MessagingProgram instance. MessagingProgram server devices SHOULD be capable of internally storing 3709 and supporting 3 unique TextMessage instances. Additional information for common application features 3710 that the Messaging function set will perform can be found in the Common Application Functionality 3711 section of this document. 3712
Messaging client devices SHALL be capable of internally storing and supporting at least 1 unique 3713 TextMessage instance, per supported MessagingProgram instance. As a highly RECOMMENDED 3714 recovery mechanism, when a maximum of storage of events has been reached and additional 3715 TextMessage instances are available on the server(s), clients SHOULD prioritize local storage and give 3716 preference to TextMessages with start times in the near future and to events with a higher PriorityType. 3717
Devices can obtain text messages from many sources. It may be very common to have multiple 3718 Messaging functions set servers in a HAN. FunctionSetAssignments and MessagingProgram.primacy are 3719 used to indicate which messaging servers in the HAN the device should prioritize. MessagingPrograms 3720 indicated in FunctionSetAssignments SHALL be of higher priority than those found through discovery. 3721 MessagingProgram.priority SHALL be used as a secondary determinant of a messages priority. 3722
12.5.4 LogEvents 3723
There are no LogEvents generated by this function set. 3724
12.6 Billing Function Set 3725
12.6.1 Overview 3726
There are several resources that are used to support billing related functions. The billing function set 3727 provides consumption or costs, estimates of future consumption, and / or historical consumption from a 3728 service provider to an end device. In addition to consumption and costs that would be calculated by the 3729 back end systems and shared with the end devices, billing also provides a mechanism to allow the service 3730 provider to push down targets or challenges to help consumers manage their budgets. A target could be a 3731 percentage or fixed value of reduction – possibly chosen by the consumer - to meet within a defined time 3732 frame. 3733
The TargetReading Resource provides a way for a service provider to create challenges or targets for an 3734 end customer to try to achieve within a certain time frame. 3735
The ProjectionReading Resource provides a way for a service provider to provide future projected 3736 consumption or cost for a particular reading type that may be calculated outside of the HAN. 3737
The HistoricalReading Resource provides a way for a service provider to provide historical consumption 3738 or cost for a particular reading type that is verified and possibly corrected at the service provider backend. 3739
The CustomerAccount resource contains information specific to the account such as the currency. The 3740 Customer Account is associated with a list of Customer Agreements. 3741
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 117 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
The Customer Agreement resource contains information about a particular agreement for service, at a 3742 particular Usage Point and a particular Tariff Profile rate. 3743
A BillingPeriod relates to a timeframe that a commodity is billed on. There may be multiple 3744 BillingPeriods that relate to different TariffProfiles. 3745
12.6.2 List Ordering 3746 Table 12-8 Billing List Ordering. 3747
Resource Name Primary Key Secondary Key Tertiary Key
CustomerAccount customerName (ascending)
mRID (descending)
N/A
CustomerAgreement serviceLocation (ascending)
mRID (descending)
N/A
BillingPeriod interval.start (descending)
href (ascending)
N/A
HistoricalReading description (ascending)
mRID (descending)
N/A
TargetReading description (ascending)
mRID (descending)
N/A
ProjectionReading description (ascending)
mRID (descending)
N/A
BillingReadingSet timePeriod.start (descending)
mRID (descending)
N/A
BillingReading timePeriod.start (ascending)
consumptionBlock (ascending)
touTier (ascending)
12.6.3 Application Guidelines / Behavior 3748
12.6.3.1 CustomerAccount and Customer Agreement Resources 3749
A CustomerAccount is related to one customer (which may be an organization). Each CustomerAccount 3750 can have multiple CustomerAgreements associated, possibly representing different UsagePoints or 3751 commodities. Each CustomerAgreement can link the associated UsagePoint (Metering), Prepayment, 3752 TariffProfile (Pricing) and / or Billing information together. Servers SHALL support at least one 3753 CustomerAccount and one CustomerAgreement if the Billing function set is implemented, and SHOULD 3754 support at least three CustomerAgreements. 3755
12.6.3.2 BillingPeriod Resource 3756
For each CustomerAgreement, there may be multiple BillingPeriods. Servers implementing the Billing 3757 function set SHALL support at least one BillingPeriod per CustomerAgreement, and SHOULD support at 3758 least three BillingPeriods per CustomerAgreement. 3759
12.6.3.3 TargetReading Resource 3760
As a good practice, there should be only one TargetReading for a BillingPeriod. The values of the target 3761 readings will be an absolute measurement similar to a projected reading. If the service provider specifies 3762 the targets in a percentage reduction or other method it MUST be converted to an absolute value. 3763
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 118 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
An example would be a customer who used 100kWh in a previous month with a reduction target of 10%. 3764 This target would be specified in the TargetReading as 90kWh and it would be left to the device to 3765 calculate the percentage or kWh reduction to which this equates. 3766
12.6.3.4 ProjectedReading Resource 3767
Projected Readings are tools for service providers to help a customer understand what their consumption 3768 or cost might be projected into the future if all things within the home stayed fairly similar. 3769
Examples of projected readings are: 3770
� Consumption for the billing period. 3771
� Cost of commodity for the billing period. 3772
� On day X the consumption would be Y which would indicate a customer moving into a higher 3773 block tariff and thus a higher rate. 3774
� The different TOU tiers at the end of the billing period based on current consumption habits. 3775
These are just examples. Other projected readings could be created. 3776
12.6.3.5 HistoricalReading Resource 3777
Historical Readings are meant to provide a resource so that a service provider can provide consumption or 3778 cost that has occurred in the past and could be validated and corrected by backoffice systems. Examples 3779 of this would be: 3780
� Previous day 3781
� Previous month 3782
� Previous billing period 3783
� Previous year 3784
� TOU A, TOU B, etc. 3785
� Block 1, Block 2, etc. 3786
� Cost of consumption for TOU A for the billing period 3787
This is just a sample of what could be used. Because the information will be provided from the backend 3788 system, it can be of billing quality or near billing quality. End devices that read consumption from 3789 metering end points will be allowed to change their local consumption reading to match information from 3790 the billing resource to allow for closer to actual billed consumption. Servers implementing the Billing 3791 function set SHALL support at least one HistoricalReading and one associated ReadingType, 3792 BillingReadingSet, and BillingReading with at least one Charge, and SHOULD support at least three of 3793 each of these, multiplied by parent containers where appropriate (e.g., three HistoricalReadings with three 3794 BillingReadingSets per HistoricalReading for a total of nine BillingReadingSets, etc.) 3795
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 119 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
12.6.3.6 Deployments with Multiple Billing Servers 3796
EndDevices that discover multiple Billing servers SHOULD differentiate between those sources on user 3797 displays of the information, unless the objects have the same mRID. 3798
12.6.4 LogEvents 3799
There are no LogEvents generated by this function set. 3800
12.7 Prepayment Function Set 3801
12.7.1 Overview 3802
The Prepayment function set defines a mechanism for the conditional delivery of services based upon 3803 outstanding credit or debt. It provides an interface for appropriately privileged clients to view, update or 3804 act upon account balance information. Accounting in prepayment systems may be measured on a 3805 monetary basis (e.g., Dollars or Euros remaining) or on a commodity basis (e.g., kilowatt-hours or BTUs 3806 remaining). A service-providing device (typically a meter) can use the account balance information from 3807 a prepayment server in combination with consumption and price data to determine if service should 3808 continue. In some scenarios ("Local" mode), the service-providing device and the prepayment server are 3809 the same. Alternatively, the continuation of service may be directed by an external prepayment server, 3810 either in response to local calculation ("ESI" mode) or to an out-of-band signal from the service provider 3811 ("Central Wallet" mode). Client devices that provide a user interface to the service provider's customers 3812 may use the prepayment function set to display information about remaining balances or to request 3813 additional credit (in some scenarios, through the transmission of payment tokens; however, note that SEP 3814 2 only provides a wrapper for this token data, the mechanism by which tokens are produced and 3815 consumed is out of scope for this specification). 3816
12.7.2 List Ordering 3817 Table 12-9 Prepayment List Ordering. 3818
Resource Name Primary Key Secondary Key Tertiary Key
Prepayment mRID (descending)
N/A N/A
Credit Register effectiveTime (descending)
mRID (descending)
N/A
SupplyInterruptionOverride interval.start (ascending)
interval.duration (ascending)
N/A
3819
12.7.3 Application Guidelines / Behavior 3820
12.7.3.1 General 3821
Servers implementing the Prepayment function set SHALL be capable of internally storing and 3822 supporting at least one Prepayment instance. Prepayment servers SHALL support one and only one 3823 AccountBalance resource per Prepayment instance. 3824
A server implementing the Prepayment function set SHALL support one and only one 3825 PrepayOperationStatus resource per Prepayment instance. 3826
Servers implementing the Prepayment function set in Local or ESI mode SHALL be capable of internally 3827 storing and supporting at least one CreditRegister instance per Prepayment instance. 3828
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 120 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Prepayment clients MAY POST to the CreditRegisterList to transmit a new CreditRegister transaction. 3829
A Prepayment client MAY PUT to PrepayOperationStatus to switch between using regular credit and 3830 emergency credit. Typically, this interface is used by service customers to tap a backup credit pool when 3831 normal credit is exhausted and cannot be immediately recharged. Prepayment server implementers MAY 3832 apply additional vendor-specific rules around when this mode of operation may be changed (e.g., 3833 emergency credit might only be allowed when availableCredit is less than or equal to the 3834 creditExpiryLevel). 3835
12.7.3.2 Prepayment Server / Usage Point Server Communication 3836
In most Prepayment configurations, client behavior is minimally affected by server state. That is, the 3837 typical client is an IHD that displays the present account and status data, posts new credit transactions, 3838 requests the use of emergency credit, or displays historical transaction data. However, in the ESI 3839 prepayment mode (and in some configurations of the Central Wallet mode), external meters (or other 3840 service-providing devices), which may be Usage Point servers, are also prepayment clients. These clients 3841 are significantly affected by server state. These devices SHALL monitor the server's Operation Status 3842 resource and should react appropriately to changes of the serviceStatus and serviceChange elements. This 3843 reaction includes connecting or disconnecting service. 3844
12.7.3.3 Mirroring Behavior 3845
In most Smart Energy 2.0 function sets, mirroring involves behavior similar to the following pattern: 3846
1) Device B issues an OPTIONS method to determine if Server A supports a POST to a given 3847 resource list. 3848
2) Device B posts its data to the resource list on Server A. Server A creates a mirrored resource for 3849 Device B. 3850
3) Client C reads Device B data from the mirrored resource on Server A. 3851
The Prepayment function set, in some deployments, requires additional mirroring behavior. With 3852 Prepayment, mirror instances MAY need to act as mailboxes for the mirrored server, such as in the 3853 following scenario: 3854
1) Device B issues an OPTIONS method to determine if Server A supports a POST to a given 3855 resource list. 3856
2) Device B posts its data to the resource list on Server A. Server A creates a mirrored resource for 3857 Device B. 3858
3) Client C POSTS data to the mirrored resource on Server A. 3859
4) Device B reads the mirrored resource on Server A to obtain Client C data. 3860
One use case for this mode is when a sleepy meter is implementing a Prepayment server in local 3861 prepayment mode. This means that the meter will be expecting CreditRegister transactions to be posted 3862 by prepayment clients. However, sleepy devices are unable to receive transmissions while idle, and a 3863 sleepy server will typically be interacting with other HAN devices through a mirrored instance. In this 3864 scenario, prepayment clients SHALL post the CreditRegister transactions to the mirrored instance. The 3865 server hosting the mirrored instance SHOULD maintain the instances of CreditRegister transactions for at 3866 least 72 hours, so that the sleepy meter MAY download and act upon the credit transactions. Note that for 3867
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 121 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
all intents and purposes (including discovery) that to Prepayment clients on the HAN, the mirrored 3868 instance is the prepayment server; the other clients are likely unaware of the sleepy device. 3869
12.7.4 LogEvents 3870 Table 12-10 Prepayment LogEvents. 3871
LogEvent Name LogEvent Code LogEvent Description PPY_CREDIT_POST_SUCCESS 0x00 SHOULD be issued when a client successfully posts a
CreditRegister to the CreditRegisterList. PPY_CREDIT_POST_FAIL 0x01 SHOULD be issued when a client posts an invalid
resource to the CreditRegisterList.
12.8 Energy Flow Reservation Function Set 3872
12.8.1 Overview 3873
This function set provides an interface for exchange of energy flow (e.g., charge or discharge) reservation 3874 events. Client devices of this function set include Plug-in Electric Vehicles, Distributed Energy Storage 3875 devices, and other managed loads that draw large amounts of power. Server devices of this function set 3876 include ESIs, EVSEs, and EMSs. FlowReservations allow for the scheduling of high demand periods 3877 such as during fast-charging transactions, to make them run at different times and avoid high aggregated 3878 demand. Typically, energy rates have penalties, charges, or customer classes for different demand tiers, so 3879 it is usually least expensive to keep the maximum demand as low as possible. Distribution utilities may 3880 support this function set to minimize the maximum demand across the distribution system. 3881
Servers accept FlowReservationRequests from client devices by exposing a FlowReservationRequestList 3882 for each EndDevice. Clients POST a request to transfer a certain amount of energy during a specific 3883 interval, at a specific rate. Servers create an associated FlowReservationResponse in the EndDevice's 3884 FlowReservationResponseList. Servers may create superseding events to modify the interval within the 3885 requested timeframe and update the status to affect client behavior and distribute load across multiple 3886 reservations. To do this, the server must have knowledge of multiple clients, but can simply approve all 3887 requests unchanged if there is no other information. 3888
12.8.2 List Ordering 3889 Table 12-11 FlowReservation List Ordering. 3890
Resource Name Primary Key Secondary Key Tertiary Key
FlowReservationRequest interval.start (ascending)
creationTime (descending)
mRID (descending)
FlowReservationResponse interval.start (ascending)
creationTime (descending)
mRID (descending)
12.8.3 Application Guidelines / Behavior 3891
12.8.3.1 FlowReservationRequest 3892
A client generates a FlowReservationRequest in order to trigger a FlowReservationResponse event from 3893 the server. 3894
FlowReservation server and client devices SHALL be capable of internally storing and supporting at least 3895 one FlowReservationRequest instance and one FlowReservationResponse instance. A FlowReservation 3896
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 122 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
server and client devices SHOULD be capable of internally storing and supporting at least three unique 3897 FlowReservationRequest instances. 3898
Clients SHALL NOT modify a FlowReservationRequest except to update the associated RequestStatus. 3899 Clients SHALL update the associated RequestStatus to Cancelled for any FlowReservationRequest that 3900 they want a server to subsequently disregard. A server SHALL return a 400 (“Bad Request”) response 3901 code if it receives a PUT of a FlowReservationRequest that contains changes other than RequestStatus. 3902
If a FlowReservationRequest is removed from the server, clients and servers SHALL NOT assume the 3903 FlowReservationRequest has been cancelled. Servers MAY remove a request as required (e.g., after the 3904 request has been fulfilled or space is needed). It is the server’s responsibility to manage 3905 FlowReservationRequests. Servers SHOULD remove FlowReservationRequests when the associated 3906 FlowReservationResponse expires. 3907
12.8.3.2 FlowReservationResponse 3908
3909
FlowReservation server and client devices SHALL be capable of internally storing and supporting at least 3910 one FlowReservationResponse instance. FlowReservation server and client devices SHOULD be capable 3911 of internally storing and supporting at least three unique FlowReservationResponse instances. 3912
A FlowReservationResponse SHALL be created in response to each FlowReservationRequest. If a server 3913 wants to deny a request, it SHALL create a FlowReservationResponse with duration equal to zero. 3914
3915
12.8.4 LogEvents 3916 Table 12-12 Flow Reservation LogEvents. 3917
LogEvent Name LogEvent Code LogEvent Description
FR_SCHEDULING_ERROR 0x00 SHOULD be issued if the server encounters an error and is unable to schedule reservations normally.
12.9 Distributed Energy Resources Function Set 3918
12.9.1 Overview 3919
This function set provides an interface to manage Distributed Energy Resources (DER). There are two 3920 main types of client devices of this function set: generation and storage. Examples of the first type include 3921 fuel cells, intelligent solar inverters, and backup generation units. Examples of the second type include 3922 battery storage systems and electric vehicles (which may not be capable of discharging). Server devices of 3923 this function set include ESIs and premises energy management systems. 3924
Servers host one or more DERPrograms, which in turn expose DERControl events to DER clients. 3925 DERControl instances contain attributes that allow DER clients to respond to events that are targeted to 3926 their device type. A DERControl instance also includes scheduling attributes that allow DER clients to 3927 store and process future events. These attributes include start time and duration, as well an indication of 3928 the need for randomization of the start and / or duration of the event. 3929
The SEP 2 DER client model is based on the SunSpec Alliance Inverter Control Model [SunSpec] which 3930 is derived from IEC 61850-90-7 [61850] and [EPRI]. As these specifications are under development at 3931 the present time, it is likely that differences will exist between the published standards. The reader is 3932
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 123 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
referred to [EPRI], [61850], and [SunSpec] for a detailed description of the DER features referred to in 3933 this function set. 3934
12.9.2 Terminology and Conventions 3935
The terminology used to describe the SEP 2 DERControl interface is relative to the DER as a power 3936 producer. A DER described here as a generator delivers active AC power for consumption in the 3937 residence or the grid. By convention, a sub-meter connected at the DER accumulates positive energy 3938 usage when the DER is delivering active power. From the utility perspective a DER operating in this 3939 mode may be viewed as a "negative load" and the premises aggregation meter will accumulate energy 3940 usage at a slowed or negative rate. 3941
When the DER has attached storage, it is described here as a load and receives active power when in 3942 charging mode. It behaves like a generator and delivers active power when in discharging mode. 3943
By convention, positive active and reactive powers flow in the same direction (here the reference 3944 direction is from the DER to the utility). When a DER is providing positive vars (i.e. behaving like an 3945 over-excited motor or generator) it is said here to be delivering reactive power (VAr). 3946
In addition to the reference frame, the SEP 2 DERControls interface defines the Power Factor (PF) sign 3947 convention used between servers and clients in order to avoid configuration mismatches. DERControl 3948 instances that affect PF assume the EEI [61850] sign convention. Negative ("lagging") PF indicates that 3949 both active and reactive powers are flowing in the same direction (either both delivered or received). Note 3950 that the EEI sign convention treats unity PF as unsigned. It may be necessary for the DER client to locally 3951 translate PF sign before issuing commands to an associated target device. 3952
These relationships are shown in Figure 12-1. At a given point in time, a DER may operate in any one of 3953 the four quadrants depending on its ability to deliver or receive active and reactive power. 3954
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 124 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
3955 3956
Figure 12-1: Active and Reactive Power Flow Directions as Measured at the DER. 3957
12.9.3 List Ordering 3958 Table 12-13 Distributed Energy Resources List Ordering. 3959
Resource Name Primary Key Secondary Key Tertiary Key
DERProgram primacy (ascending)
mRID (descending)
N/A
DERControl and ActiveDERControl
interval.start (ascending)
creationTime (descending)
mRID (descending)
DERCurve creationTime (descending)
mRID (descending)
N/A
DER href (ascending)
N/A N/A
12.9.4 Application Guidelines / Behavior 3960
12.9.4.1 DERProgram 3961
Multiple programs can be created to target different types of devices or to offer different types of 3962 incentives. A DER client will typically discover its associated DERProgramList through Function Set 3963 Assignments. 3964
Active Power Received (W) Active Power Delivered (W)Rea
ctiv
e P
ower
Del
iv. (
var)
Rea
ctiv
e P
ower
Rec
. (va
r)
Q(+)
P(+)
Over-excited
Under-excited
III
III IV
Power Factor signEEI: + (leading)IEC: -
Power Factor signEEI: - (lagging)IEC: -
Power Factor signEEI: - (lagging)IEC: +
Power Factor signEEI: + (leading)IEC: +
Q(-)
P(-)(charging) (discharging and/or generating)
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 125 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
DERProgram server devices SHALL be capable of internally storing and supporting at least one 3965 DERProgram instance. DERProgram server devices SHOULD be capable of internally storing and 3966 supporting three unique DERProgram instances. Each DERProgram instance SHALL be uniquely 3967 identified by an mRID. 3968
DER client devices SHALL be capable of internally storing and supporting at least one DERProgram 3969 instance. DER client devices SHOULD be capable of internally storing and supporting two unique 3970 DERProgram instances. 3971
12.9.4.2 DERControl 3972
A DERProgram exposes control parameters to a DER client via DERControl Events. At any point in time 3973 a DER client is managed by a single DERControl Event, which SHALL supersede any previous Event. A 3974 DER client MAY reject or partially act upon a DERControl Event based on its capabilities. The control 3975 mode(s) supported by a DER may be determined from its DERCapability.modesSupported attribute. If 3976 there are no active Events, the DER client SHALL be managed by the DefaultDERControl instance 3977 exposed by the preferred DERProgram. 3978
DERProgram server devices SHALL be capable of internally storing and supporting at least five unique 3979 DERControl instances, which MAY be distributed among multiple programs. DERProgram server 3980 devices SHOULD be capable of internally storing and supporting a total of 10 unique DERControl 3981 instances. Each DERProgram SHALL internally store a single DefaultDERControl instance that defines 3982 the default behavior of associated DER clients when no active Events are available. Each DERControl 3983 and DefaultDERControl instance SHALL be uniquely identified by an mRID. 3984
DER client devices SHALL be capable of internally storing and supporting at least one DERControl 3985 instance and a single DefaultDERControl instance for each stored DERProgram. DER client devices 3986 SHOULD be capable of internally storing and supporting three DERControl instances. DER clients 3987 SHOULD prioritize local storage and give preference to DERControls with start times in the near future. 3988
DERControl modes are divided into two categories. Immediate control modes (opModFixedW, 3989 opModFixedPF, opModFixedVAr, opModFixedFlow) request a fixed output setting that the DER client 3990 SHOULD attempt to satisfy. Curve-based control modes allow a DER client to dynamically vary an 3991 output (dependent variable) as a function of a given input signal (independent variable). For example, an 3992 intelligent inverter may support the Volt-Watt mode and dynamically control its active power delivery 3993 based on local voltage measurements. Curve-based control modes are based on DERCurve instances. 3994
12.9.4.3 DERCurve 3995
The DERCurves associated with a given DERProgram are grouped under the program's DERCurveList 3996 resource. Each DERCurve SHALL contain a defined curveType value that associates the curve with a 3997 given control mode and implicitly defines the units of measure that apply to its curveData points. 3998
A DERCurve SHALL specify an array of one or more curveData points. Watt-PowerFactor curve types 3999 SHALL specify two dependent variables (yvalue plus excitation) per curveData point. All other curve 4000 types define a single independent variable (xvalue) and dependent variable (yvalue) per curveData point. 4001 See the schema [ZB 13-0201] for details on curve-based DER control modes. 4002
Implementations SHALL support a minimum of four curves having a minimum of 10 points per curve for 4003 each curve-based DERControl mode supported, unless otherwise specified. 4004
As shown in Figure 12-2, an array of points may be used to represent a piecewise linear curve with 4005 hysteresis. This allows flexibility in defining stable behavior, differences in ramp rates, etc. 4006 4007
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 126 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
4008 4009
4010
Figure 12-2: Example Volt-VAr Curve and Hysteresis 4011
Figure 12-3 shows the DER operating regions defined by LVRT / HVRT curves. LVRT / HVRT curves 4012 are assumed to extend horizontally to the left to zero seconds before the first point in the array and to the 4013 right horizontally after the right-most point in the array. 4014
4015
Figure 12-3: Example Low and High - Voltage Ride Through Curves 4016
Over-excited (+)
Voltage Rising
Effective Percent Voltage
P1 {99%V, 50% statVArAvail}
P3 {101% V, -50% statVArAvail}
% A
vaila
ble
VArs
Under-excited (-)
{97% V, 50% statVArAvail} P4
Voltage Falling
P2 {103% V, -50% statVArAvail}
jitter
Remaining Connected or Disconnected is Allowed
Must Disconnect
Must Remain Connected
Must Remain Connected
Remaining Connected or Disconnected is Allowed
Must Disconnect
Nominal Voltage
Event Duration (sec)
P1
P2 P3
P4P1
P2
P1 P1
P2 P3
P4
P2 P3
P4
% V
olta
ge
HVRT
LVRT
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 127 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
12.9.4.4 DER Info Resources 4017
A DER MAY be modeled as one or more DER client instances. For example, a device that consists of a 4018 solar inverter with attached storage may be modeled as separate or combined generation and storage 4019 DERs, depending on the complexity of the device's local control interface. The DER resource exposes the 4020 capability limits of a specific Distributed Energy Resource, as well as basic settings, status, and 4021 availability. A DER client SHOULD store these resources locally. 4022
The currently executing DERProgram SHALL be referenced by the DER's CurrentDERProgramLink. 4023 This DERProgram instance SHOULD reference local copies of the active DERControl and DERCurves. 4024
12.9.4.4.1 DERCapability 4025
The DER resource exposes the capabilities of a specific Distributed Energy Resource, referred to as its 4026 "nameplate ratings". Ratings are read-only values established by the DER manufacturer by design or 4027 manufactured configuration, e.g. the continuous delivered active power rating capability in watts (rtgW), 4028 and are available by reading the DERCapability resource. 4029
12.9.4.4.2 DERSettings 4030
The DERSettings resource provides a means to adjust the operating limits of a DER device as established 4031 by its nameplate ratings. For example, the active power output (setMaxW) may be reduced or increased as 4032 a function of attached photo-voltaic panels, condition of the equipment, season of the year, or intended 4033 use, subject to the maximum limit by rtgMaxW. 4034
The basic settings also include configuration settings related to a specific installation such as setVRef, the 4035 nominal voltage at the point of common coupling; setVRefOfs, the voltage difference from the point of 4036 common coupling to the electrical connection point of the inverter; and the set point for the nominal 4037 frequency. Each rating value in a DER's DERCapability instance MAY have a corresponding setting 4038 value in its DERSettings instance (which equals the rating value by default). A modified rating SHALL 4039 have a corresponding setting. 4040
12.9.4.4.3 DERStatus 4041
The DER resource references a DERStatus instance that contains basic operational status attributes for the 4042 DER device. Information such as accumulated generation readings SHOULD be made available by a sub-4043 meter referenced by the DER's AssociatedUsagePointLink. 4044
12.9.4.4.4 DER Availability 4045
The DERAvailability object is used by client devices to report their availability to deliver reserve active 4046 and reactive power. It MAY also be exposed instead by devices that are able to report this information on 4047 behalf of other devices. Duration attributes MAY be provided to indicate how long the generation can be 4048 sustained. 4049
12.9.5 DER Client Device Requirements 4050
DER device architectures are expected to vary widely. Therefore, minimum required functionality is 4051 based on DER type. A DER instance SHOULD be as simple as possible, but no simpler. For example, if a 4052 generator type DER can deliver reactive power and supports fixed VAr control mode then it must include 4053 rtgVAr and setMaxVAr. 4054
If there is a significant difference between delivered and received VAr capability, then the DER MAY 4055 also include rtgVArNeg and setMaxVArNeg or use rtgVAr to specify a common (minimum) rating for 4056 both delivered and received VAr. Similarly, if a device includes attached storage and the charging and 4057 discharging mode rating limits differ significantly then the device can be modeled as separate DERs. 4058
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 128 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Each unique DER instance SHALL link to a DERCapability instance that SHALL contain type, 4059 modesSupported, rtgA, and rtgW attributes. The type attribute determines which additional modes and 4060 attributes are required as shown in the tables below. 4061
The tables are interpreted as follows. If the optionality key in the column Opt1 is "M" (mandatory) then 4062 the DER SHALL support the control mode(s) listed under modesSupported; if the key is "R" 4063 (recommended) then the DER SHOULD support the listed control mode; if the key is "O" (optional) then 4064 the DER MAY support the listed control mode. 4065
If the optionality key in the column Opt2 is "M" (mandatory) then the DER SHALL include the 4066 attribute(s) listed in the column Related attribute(s); if the key is "R" (recommended) then the DER 4067 SHOULD support the listed attribute; if the key is "O" (optional) then the DER MAY support the listed 4068 attribute. 4069
If multiple modes are listed in a given entry, then support for any one of them meets the requirement. 4070 Each mode will then be individually listed together with its required attributes. If multiple attributes are 4071 listed in a given entry, then support for any one of them meets the requirement. For example, a storage 4072 DER that supports only charging (e.g. a PEV) may choose to omit rtgMaxChargeRate and expose its 4073 maximum charging rate via the rtgW attribute. However, if a storage DER also supports discharge mode 4074 then it MUST use rtgMaxChargeRate to expose its charging rate and MAY use either 4075 rtgMaxDischargeRate (if the DER supports simultaneous generation and discharge) or rtgW to expose its 4076 maximum discharging rate. 4077
Table 12-14 Modes and Attributes for Generator Type DERs. 4078
Opt1 modesSupported Opt2 Related attribute(s) Notes
M 12 - Fixed W M rtgW/setMaxW Continuous active power output (includes max discharge rate if combined generator / storage type)
O rtgVA/setMaxVA Continuous apparent power out
M 3 - Volt-Watt
R 13 - Fixed VAr or 14 - Fixed PF
13 - Fixed VAr
M rtgVAr/setMaxVAr If Fixed VAr mode is supported, then Volt-VAr mode SHOULD be supported
O rtgVArNeg/ setMaxVArNeg
SHOULD be included if received and delivered VAr differ significantly
14 - Fixed PF M rtgMinPF/setMinPF If Fixed PF mode is supported, then Watt-PF mode SHOULD be supported
O rtgMinPFNeg/ setMinPFNeg
SHOULD be included if received and delivered VAr differ significantly
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 129 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
4079
Most DERs will typically act as generators, with the possible exception of DERType 81 (electric vehicle). 4080
Table 12-15 Modes and Attributes for Storage Type DERs. 4081
Opt1 modesSupported Opt2 Related attribute(s) Notes
M 15 - Charge mode M rtgMaxChargeRate/ setMaxChargeRate or rtgW/setMaxW
rtgMaxChargeRate is "M" if Discharge mode is supported
M rtgWh or rtgAh Storage capacity
O 16 - Discharge mode M rtgMaxChargeRate/ setMaxChargeRate
M rtgMaxDischargeRate/ setMaxDischargeRate or rtgW/setMaxW
rtgMaxDischargeRate is "M" if combined generator / storage type
4082
Storage type DERs include DERType 80 (immobile storage), 81, and 82 (combined PV and storage). 4083 Note that remote connect and disconnect functions for generator and storage DERs are not control modes 4084 but settings, and SHOULD be included in DERSettings. 4085
12.9.6 LogEvents 4086
There are no LogEvents generated by this function set. 4087
12.10 Metering Mirror 4088
12.10.1 Overview 4089
The Metering Mirror function set provides a mechanism for constrained devices to post metering data to a 4090 Metering server in a very efficient manner. Great effort has gone into minimizing the number of 4091 transactions needed to create and maintain the mirroring relationship. Therefore mechanisms and 4092 structures of this function set differ from other function sets to attain this efficiency. 4093
12.10.2 List Ordering 4094 Table 12-16 Metering Mirror List Ordering. 4095
Resource Name Primary Key Secondary Key Tertiary Key
MirrorUsagePoint mRID (descending)
NA NA
12.10.3 Application Guidelines / Behavior 4096
A Metering Mirror function set server SHALL NOT advertise support for mirroring unless it has the 4097 resources available to host at least one additional mirror. The server must have room for at least one 4098 instance of each of the resources possible under a Usage Point. 4099
The following rules apply to creating and maintaining Metering Mirrors. 4100
1) To create a new Metering Mirror the client SHALL POST to the server's MirrorUsagePointList 4101 (e.g., /mup) for the mirrored usage point. 4102
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 130 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
a) This POST SHALL contain at least the information through the definition of 4103 MirrorMeterReadings and ReadingType including the MirrorUsagePoint mRID and 4104 MirrorMeterReading mRIDs. 4105
b) The POST MAY also contain MirrorReadingSets and Readings. 4106
c) If the mRID of the MirrorUsagePoint is unique (does not match a 4107 MirrorUsagePoint.mRID of an existing MirrorUsagePoint) the response SHALL be 4108 response code 201 (Created), the MirrorUsagePoint URI SHALL be included in the 4109 Location header. 4110
d) If the mRID of the MirrorUsagePoint matches an existing MirrorUsagePoint, the new 4111 data SHALL be written over the existing MirrorUsagePoint (and associated UsagePoint) 4112 and the response code SHALL be 204 (No Content), the MirrorUsagePoint URI SHALL 4113 be included in the Location header. If the MirrorUsagePoint contains 4114 MirrorMeterReadings, then the guidance of rules 8 and 9 are to be applied. 4115
2) When the Metering Mirror function set server receives a POST it SHALL copy the received data, 4116 including mRIDs, into the normal metering structure to its Metering UsagePoint structure 4117 (e.g., /upt), and it SHALL allocate enough resources to manage the mirror and its data. 4118
3) A GET of the resource (MirrorUsagePoint) identified in the response to the initial POST SHALL 4119 return a resource with only the first level elements (i.e., sub-elements and collections are not 4120 included). 4121
4) To POST new data to an existing MirrorUsagePoint, the Metering client SHALL POST a 4122 MirrorMeterReading or MirrorMeterReadingList containing MirrorReadingSets and/or Readings 4123 to the resource identified in the Metering server's response to the POST that created the resource 4124 (e.g., /mup/3). 4125
5) The Metering Mirror server SHOULD only accept POSTs to a given MirrorUsagePoint from the 4126 client that created the mirror. 4127
6) If a POST to the MirrorUsagePoint is of a MirrorMeterReading then a successful response 4128 SHALL contain a Location header indicating the URI of the MeterReading resource under the 4129 associated UsagePoint (e.g., /upt/2/mr/3). 4130
7) If a POST to the MirrorUsagePoint is of a MirrorMeterReadingList then a successful response 4131 SHALL contain a Location header indicating the URI of the MeterReadingList under the 4132 associated UsagePoint (e.g., /upt/2/mr). 4133
8) In a POST to the MirrorUsagePoint, the mRID attribute of the MirrorMeterReading(s) SHALL be 4134 used by the Metering Mirror server to associate the data in a POST with the MeterReading in the 4135 associated UsagePoint. 4136
a) In a POST to the MirrorUsagePoint, if the mRID attribute matches a previous 4137 MirrorMeterReading then the contained MirrorReadingSets SHALL be added to the 4138 associated MeterReading and a contained Reading SHALL replace the existing Reading. 4139 The contents of the MirrorMeterReading shall overwrite the data in the associated 4140 MeterReading. 4141
b) In a POST to the MirrorUsagePoint, if the mRID does not match a previous 4142 MirrorMeterReading and it contains a ReadingType, a new MeterReading SHALL be 4143 created under the associated UsagePoint with the new data. 4144
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 131 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
c) In a POST to the MirrorUsagePoint, if the mRID does not match a previous 4145 MirrorMeterReading and there is not a ReadingType then the request SHALL be rejected 4146 with a response code 400 (Bad Request). 4147
9) In a POST to the MirrorUsagePoint, where the request is not rejected, the new data SHALL be 4148 applied to the related UsagePoint resource structure according to the following: 4149
a) If a MirrorReadingSet is received with a duplicate mRID of an existing ReadingSet, and 4150 it is targeted within the same resource hierarchy, then the new data SHALL replace the 4151 existing data of the identified ReadingSet. 4152
b) If a MirrorReadingSet is received with a unique mRID then the new data SHALL be 4153 added to the identified ReadingSetList. 4154
10) If a client POSTs more data than the Metering Mirror server is willing to accept, the server 4155 SHALL respond with a response code of 413 (Request Entity Too Large). 4156
11) The Metering Mirror server MAY decide when to remove data from the related UsagePoint 4157 resource structure. 4158
A Metering Mirror function set server MAY implement a timeout mechanism on a mirror. If a Metering 4159 Mirror function set server does not receive any POSTs from a Metering Mirror function set client for 4160 more than a specified time the server MAY remove the MirrorUsagePoint resource and its related 4161 UsagePoint resource. The recommended timeout is 72 hours. 4162
12.10.4 LogEvents 4163 Table 12-17 Metering Mirror LogEvents. 4164
LogEvent Name LogEvent Code LogEvent Description
MUP_MIRROR_EXPIRED 0x00 SHOULD be generated by a server when a Metering Mirror expires.
4165
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 132 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
13 Manufacturer – Specific Proprietary Extensions 4166
13.1 Overview 4167
This section describes rules and mechanisms for interested parties to extend the Smart Energy Profile 2.0 4168with proprietary extensions. 4169
It should be noted that as the Smart Energy Profile 2.0 is intended to run over an IP stack, many 4170techniques already exist for providing proprietary services over such a stack with various protocols. This 4171section is intended for guidance to developers of proprietary extensions that may wish to be similar to the 4172design of the Smart Energy Profile 2.0 or add extended elements to the Smart Energy Profile 2.0. 4173
13.2 xmDNS/DNS-SD 4174
Proprietary extensions SHALL NOT be made using the "smartenergy" Service Type. 4175
It is RECOMMENDED that proprietary extensions that wish to use xmDNS/DNS-SD apply for a new 4176Service Type with which to operate. 4177
13.3 URIs 4178
As URIs are dynamically discovered and used, proprietary extensions are free to place proprietary 4179resources at URIs of their choosing. It is RECOMMENDED that proprietary resources not be placed at 4180URIs 'RECOMMENDED' in this specification and in [ZB 13-0201]. 4181
13.4 Resources 4182
Proprietary extensions SHALL NOT place any objects, elements, attributes, etc. in the standardized SEP 4183XML namespace ("http://zigbee.org/sep") and instead SHALL be placed in a different XML namespace. 4184
The following examples demonstrate allowed and disallowed extensions. In these examples, 4185"SEPElement{#}" is used to demonstrate elements that are defined in the SEP schema. 4186"MFEElement{#}" and "MFENS" are used to demonstrate elements and namespaces that are proprietary 4187extensions respectively. 4188
The example given below demonstrates allowed and disallowed (crossed out) element extensions. 4189
<SEPElement1 xmlns="http://zigbee.org/sep"> <SEPElement2>a</SEPElement2> <SEPElement3>b</SEPElement3> <MFEElement1>c</MFEElement1></SEPElement1>
<SEPElement1 xmlns="http://zigbee.org/sep" xmlns:MFENS="http://foo.org/mfe"> <SEPElement2>a</SEPElement2> <SEPElement3>b</SEPElement3> <MFENS:MFEElement1>c</MFENS:MFEElement1></SEPElement1>
mentc</MF
1
l
g/se>
emenment
PElement2
/SEP
Allowed Disallowed
4190
Figure 13-1: Allowed and Disallowed Extension 4191
Proprietary extensions SHALL NOT extend enumerations defined in the SEP 2 schema. 4192
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 133 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Proprietary extensions made to standardized objects (in a proprietary namespace) defined in the SEP 2 4193 schema SHALL be able to be ignored. That is, a device that does not understand a proprietary extension 4194 can safely ignore the extension. 4195
Proprietary extensions made to standardized objects (in a proprietary namespace) defined in the SEP 2 4196 schema SHALL NOT change the semantics of elements and attributes defined in the SEP 2 schema. 4197
13.5 DeviceCapabilities Resource 4198
It is RECOMMENDED that proprietary extensions use a different resource in which to list further 4199 resources. 4200
Should a proprietary extension wish to use the standard DeviceCapabilities resource, it MUST do so 4201 following the same rules as for other resources. 4202
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 134 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
14 Appendix A - Web-Application Description Language (INFORMATIVE) 4203
Note that the WADL (sep_wadl.xml, contained in [ZB 13-0201]) is NORMATIVE. This section presents 4204 a human-friendly view of the information to facilitate understanding. 4205
14.1 Support Resources Section 4206
14.1.1 Device Capability Function Set 4207
14.1.1.1 DeviceCapability Resource 4208
Used to determine the resources available on a server. 4209
Sample URI: /dcap 4210 Request Representation: DeviceCapability 4211 Response Representation: DeviceCapability 4212 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Error 4213
14.1.2 Self Device Resource Function Set 4214
14.1.2.1 SelfDevice Resource 4215
The device that is providing the services being accessed. 4216
Sample URI: /sdev 4217 Request Representation: SelfDevice 4218 Response Representation: SelfDevice 4219 Methods: GET/HEAD: Mandatory, PUT: Discouraged, POST: Error, DELETE: Error 4220
14.1.3 End Device Resource Function Set 4221
14.1.3.1 EndDeviceList Resource 4222
End device resource list. 4223
Sample URI: /edev 4224 Request Representation: EndDevice 4225 Response Representation: EndDeviceList 4226 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Optional, DELETE: Error 4227
14.1.3.2 EndDevice Resource 4228
End device instance. 4229
Sample URI: /edev/{id1} 4230 Request Representation: EndDevice 4231 Response Representation: EndDevice 4232 Methods: GET/HEAD: Mandatory, PUT: Optional, POST: Error, DELETE: Optional 4233
14.1.3.3 Registration Resource 4234
Contains registrations related to the indicated device. 4235
Sample URI: /edev/{id1}/rg 4236 Request Representation: Registration 4237 Response Representation: Registration 4238 Methods: GET/HEAD: Mandatory, PUT: Optional, POST: Error, DELETE: Optional 4239
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 135 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
14.1.3.4 DeviceStatus Resource 4240
Contains the current operational state of the associated EndDevice or SelfDevice. 4241
Sample URI: /edev/{id1}/dstat 4242 Request Representation: DeviceStatus 4243 Response Representation: DeviceStatus 4244 Methods: GET/HEAD: Mandatory, PUT: Mandatory, POST: Error, DELETE: Optional 4245
14.1.4 Function Set Assignments Function Set 4246
14.1.4.1 FunctionSetAssignmentsList Resource 4247
Contains function set assignments present on the server and/or related to the indicated device. 4248
Sample URI: /edev/{id1}/fsa 4249 Request Representation: FunctionSetAssignments 4250 Response Representation: FunctionSetAssignmentsList 4251 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Discouraged, DELETE: Error 4252
14.1.4.2 FunctionSetAssignments Resource 4253
Contains links to the specific function set assignments. 4254
Sample URI: /edev/{id1}/fsa/{id2} 4255 Request Representation: FunctionSetAssignments 4256 Response Representation: FunctionSetAssignments 4257 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Discouraged 4258
14.1.5 Subscription/Notification Mechanism Function Set 4259
14.1.5.1 SubscriptionList Resource 4260
Contains subscriptions related to the indicated device. Documented in Subscription / Notification 4261 Mechanism. 4262
Sample URI: /edev/{id1}/sub 4263 Request Representation: Subscription 4264 Response Representation: SubscriptionList 4265 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Mandatory, DELETE: Error 4266
14.1.5.2 Subscription Resource 4267
A specific subscription 4268
Sample URI: /edev/{id1}/sub/{id2} 4269 Request Representation: Subscription 4270 Response Representation: Subscription 4271 Methods: GET/HEAD: Mandatory, PUT: Mandatory, POST: Error, DELETE: Mandatory 4272
14.1.5.3 NotificationList Resource 4273
A list of notifications 4274
Sample URI: /ntfy 4275 Request Representation: Notification 4276 Response Representation: NotificationList 4277 Methods: GET/HEAD: Discouraged, PUT: Error, POST: Mandatory, DELETE: Error 4278
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 136 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
14.1.5.4 Notification Resource 4279
A specific notification 4280
Sample URI: /ntfy/{id1} 4281 Request Representation: Notification 4282 Response Representation: Notification 4283 Methods: GET/HEAD: Discouraged, PUT: Error, POST: Error, DELETE: Error 4284
14.1.6 Response Function Set 4285
14.1.6.1 ResponseSetList Resource 4286
List of ResponseSet instances or channels. Devices implementing the ResponseSetList resource MAY 4287 support multiple instances of ResponseSet 4288
Sample URI: /rsps 4289 Request Representation: ResponseSet 4290 Response Representation: ResponseSetList 4291 Methods: GET/HEAD: Optional, PUT: Error, POST: Discouraged, DELETE: Error 4292
14.1.6.2 ResponseSet Resource 4293
Specific ResponseSet instance. This resource can be thought of as a particular ResponseList or channel. 4294
Sample URI: /rsps/{id1} 4295 Request Representation: ResponseSet 4296 Response Representation: ResponseSet 4297 Methods: GET/HEAD: Optional, PUT: Error, POST: Error, DELETE: Discouraged 4298
14.1.6.3 ResponseList Resource 4299
List of Response instances. 4300
Sample URI: /rsps/{id1}/rsp 4301 Request Representation: Response 4302 Response Representation: ResponseList 4303 Methods: GET/HEAD: Optional, PUT: Error, POST: Mandatory, DELETE: Error 4304
14.1.6.4 Response Resource 4305
Specific Response instance. 4306
Sample URI: /rsps/{id1}/rsp/{id2} 4307 Request Representation: Response 4308 Response Representation: Response 4309 Methods: GET/HEAD: Optional, PUT: Error, POST: Error, DELETE: Optional 4310
14.1.6.5 PriceResponse Resource 4311
A specific PriceResponse instance. 4312
Sample URI: /rsps/{id1}/rsp/{id2} 4313 Request Representation: PriceResponse 4314 Response Representation: PriceResponse 4315 Methods: GET/HEAD: Optional, PUT: Error, POST: Error, DELETE: Optional 4316
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 137 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
14.1.6.6 TextResponse Resource 4317
A specific TextMessage Response instance. 4318
Sample URI: /rsps/{id1}/rsp/{id2} 4319 Request Representation: TextResponse 4320 Response Representation: TextResponse 4321 Methods: GET/HEAD: Optional, PUT: Error, POST: Error, DELETE: Optional 4322
14.1.6.7 DrResponse Resource 4323
A specific Demand Response / Load Control EndDeviceControl Response (DrResponse) instance. 4324
Sample URI: /rsps/{id1}/rsp/{id2} 4325 Request Representation: DrResponse 4326 Response Representation: DrResponse 4327 Methods: GET/HEAD: Optional, PUT: Error, POST: Error, DELETE: Optional 4328
14.2 Common Resources Section 4329
14.2.1 Time Function Set 4330
14.2.1.1 Time Resource 4331
Provides the Time Resource. 4332
Sample URI: /tm 4333 Request Representation: Time 4334 Response Representation: Time 4335 Methods: GET/HEAD: Mandatory, PUT: Discouraged, POST: Error, DELETE: Error 4336
14.2.2 Device Information Function Set 4337
14.2.2.1 DeviceInformation Resource 4338
Device Information of the associated EndDevice or SelfDevice. 4339
Sample URI: /edev/{id1}/di 4340 Request Representation: DeviceInformation 4341 Response Representation: DeviceInformation 4342 Methods: GET/HEAD: Mandatory, PUT: Mandatory, POST: Error, DELETE: Optional 4343
14.2.2.2 SupportedLocaleList Resource 4344
A List of supported locales for the associated EndDevice or SelfDevice. 4345
Sample URI: /edev/{id1}/di/loc 4346 Request Representation: SupportedLocale 4347 Response Representation: SupportedLocaleList 4348 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Mandatory, DELETE: Error 4349
14.2.2.3 SupportedLocale Resource 4350
A specific supported locale for the associated EndDevice or SelfDevice. 4351
Sample URI: /edev/{id1}/di/loc/{id2} 4352 Request Representation: SupportedLocale 4353 Response Representation: SupportedLocale 4354
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 138 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Methods: GET/HEAD: Mandatory, PUT: Mandatory, POST: Error, DELETE: Mandatory 4355
14.2.3 Power Status Function Set 4356
14.2.3.1 PowerStatus Resource 4357
Contains the power status for the associated EndDevice or SelfDevice. 4358
Sample URI: /edev/{id1}/ps 4359 Request Representation: PowerStatus 4360 Response Representation: PowerStatus 4361 Methods: GET/HEAD: Mandatory, PUT: Mandatory, POST: Error, DELETE: Error 4362
14.2.4 Network Status Function Set 4363
14.2.4.1 IPInterfaceList Resource 4364
List of IPInterface instances on the associated EndDevice or SelfDevice. 4365
Sample URI: /edev/{id1}/ns 4366 Request Representation: IPInterface 4367 Response Representation: IPInterfaceList 4368 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Optional, DELETE: Error 4369
14.2.4.2 IPInterface Resource 4370
Specific IPInterface resource. This resource may be thought of as network status information for a 4371 specific network (IP) layer interface. 4372
Sample URI: /edev/{id1}/ns/{id2} 4373 Request Representation: IPInterface 4374 Response Representation: IPInterface 4375 Methods: GET/HEAD: Mandatory, PUT: Optional, POST: Error, DELETE: Optional 4376
14.2.4.3 IPAddrList Resource 4377
List of IP Addresses 4378
Sample URI: /edev/{id1}/ns/{id2}/addr 4379 Request Representation: IPAddr 4380 Response Representation: IPAddrList 4381 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Optional, DELETE: Error 4382
14.2.4.4 IPAddr Resource 4383
A specific IP Address 4384
Sample URI: /edev/{id1}/ns/{id2}/addr/{id3} 4385 Request Representation: IPAddr 4386 Response Representation: IPAddr 4387 Methods: GET/HEAD: Mandatory, PUT: Optional, POST: Error, DELETE: Optional 4388
14.2.4.5 RPLInstanceList Resource 4389
List of RPL instances that the IPAddr is a member 4390
Sample URI: /edev/{id1}/ns/{id2}/addr/{id3}/rpl 4391 Request Representation: RPLInstance 4392 Response Representation: RPLInstanceList 4393
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 139 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Methods: GET/HEAD: Mandatory, PUT: Error, POST: Optional, DELETE: Error 4394
14.2.4.6 RPLInstance Resource 4395
A specific RPL Instance 4396
Sample URI: /edev/{id1}/ns/{id2}/addr/{id3}/rpl/{id4} 4397 Request Representation: RPLInstance 4398 Response Representation: RPLInstance 4399 Methods: GET/HEAD: Mandatory, PUT: Optional, POST: Error, DELETE: Optional 4400
14.2.4.7 RPLSourceRoutesList Resource 4401
List of RPL source routes 4402
Sample URI: /edev/{id1}/ns/{id2}/addr/{id3}/rpl/{id4}/srt 4403 Request Representation: RPLSourceRoutes 4404 Response Representation: RPLSourceRoutesList 4405 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Optional, DELETE: Error 4406
14.2.4.8 RPLSourceRoutes Resource 4407
A specific RPL source route 4408
Sample URI: /edev/{id1}/ns/{id2}/addr/{id3}/rpl/{id4}/srt/{id5} 4409 Request Representation: RPLSourceRoutes 4410 Response Representation: RPLSourceRoutes 4411 Methods: GET/HEAD: Mandatory, PUT: Optional, POST: Error, DELETE: Optional 4412
14.2.4.9 LLInterfaceList Resource 4413
List of Link Layer Interfaces 4414
Sample URI: /edev/{id1}/ns/{id2}/ll 4415 Request Representation: LLInterface 4416 Response Representation: LLInterfaceList 4417 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Optional, DELETE: Error 4418
14.2.4.10 LLInterface Resource 4419
A specific Link Layer Interface 4420
Sample URI: /edev/{id1}/ns/{id2}/ll/{id3} 4421 Request Representation: LLInterface 4422 Response Representation: LLInterface 4423 Methods: GET/HEAD: Mandatory, PUT: Optional, POST: Error, DELETE: Optional 4424
14.2.4.11 NeighborList Resource 4425
List of 802.15.4 neighbors 4426
Sample URI: /edev/{id1}/ns/{id2}/ll/{id3}/nbh 4427 Request Representation: Neighbor 4428 Response Representation: NeighborList 4429 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Optional, DELETE: Error 4430
14.2.4.12 Neighbor Resource 4431
A specific 802.15.4 neighbor 4432
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 140 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Sample URI: /edev/{id1}/ns/{id2}/ll/{id3}/nbh/{id4} 4433 Request Representation: Neighbor 4434 Response Representation: Neighbor 4435 Methods: GET/HEAD: Mandatory, PUT: Optional, POST: Error, DELETE: Optional 4436
14.2.5 Log/Event Log Function Set 4437
14.2.5.1 LogEventList Resource 4438
A List of LogEvent instances. 4439
Sample URI: /edev/{id1}/lel 4440 Request Representation: LogEvent 4441 Response Representation: LogEventList 4442 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Mandatory, DELETE: Error 4443
14.2.5.2 LogEvent Resource 4444
A specific LogEvent entry from the LogEventList. 4445
Sample URI: /edev/{id1}/lel/{id2} 4446 Request Representation: LogEvent 4447 Response Representation: LogEvent 4448 Methods: GET/HEAD: Mandatory, PUT: Optional, POST: Error, DELETE: Mandatory 4449
14.3 Smart Energy Resources Section 4450
14.3.1 Configuration Resource Function Set 4451
14.3.1.1 Configuration Resource 4452
Contains the configuration settings of the associated EndDevice or SelfDevice. 4453
Sample URI: /edev/{id1}/cfg 4454 Request Representation: Configuration 4455 Response Representation: Configuration 4456 Methods: GET/HEAD: Mandatory, PUT: Mandatory, POST: Error, DELETE: Error 4457
14.3.1.2 PriceResponseCfgList Resource 4458
Contains a List of price response configuration settings. 4459
Sample URI: /edev/{id1}/prcfg 4460 Request Representation: PriceResponseCfg 4461 Response Representation: PriceResponseCfgList 4462 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Mandatory, DELETE: Error 4463
14.3.1.3 PriceResponseCfg Resource 4464
Contains the price response configuration settings for this EndDevice associated with a RateComponent. 4465
Sample URI: /edev/{id1}/prcfg/{id2} 4466 Request Representation: PriceResponseCfg 4467 Response Representation: PriceResponseCfg 4468 Methods: GET/HEAD: Mandatory, PUT: Mandatory, POST: Error, DELETE: Mandatory 4469
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 141 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
14.3.2 Software Download Function Set 4470
14.3.2.1 FileList Resource 4471
A list of files 4472
Sample URI: /file 4473 Request Representation: File 4474 Response Representation: FileList 4475 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Discouraged, DELETE: Error 4476
14.3.2.2 File Resource 4477
A specific file 4478
Sample URI: /file/{id1} 4479 Request Representation: File 4480 Response Representation: File 4481 Methods: GET/HEAD: Mandatory, PUT: Discouraged, POST: Error, DELETE: Discouraged 4482
14.3.2.3 FileStatus Resource 4483
The file status of a particular file download for the associated EndDevice or SelfDevice. 4484
Sample URI: /edev/{id1}/fs 4485 Request Representation: FileStatus 4486 Response Representation: FileStatus 4487 Methods: GET/HEAD: Mandatory, PUT: Mandatory, POST: Error, DELETE: Error 4488
14.3.3 Demand Response and Load Control Function Set 4489
14.3.3.1 DemandResponseProgramList Resource 4490
List of DemandResponseProgram instances. Devices implementing the DemandResponseProgramList 4491 resource MAY support multiple instances of DemandResponsePrograms. 4492
Sample URI: /dr 4493 Request Representation: DemandResponseProgram 4494 Response Representation: DemandResponseProgramList 4495 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Discouraged, DELETE: Error 4496
14.3.3.2 DemandResponseProgram Resource 4497
Specific DemandResponseProgram resource. This resource can be thought of as a particular 4498 DemandResponseProgram endpoint. 4499
Sample URI: /dr/{id1} 4500 Request Representation: DemandResponseProgram 4501 Response Representation: DemandResponseProgram 4502 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Discouraged 4503
14.3.3.3 ActiveEndDeviceControlList Resource 4504
List of EndDeviceControls that are currently active. 4505
Sample URI: /dr/{id1}/actedc 4506 Request Representation: EndDeviceControl 4507 Response Representation: EndDeviceControlList 4508
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 142 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Error 4509
14.3.3.4 EndDeviceControlList Resource 4510
List of EndDeviceControls. Devices implementing the EndDeviceControlList resource MAY support 4511 multiple EndDeviceControls. 4512
Sample URI: /dr/{id1}/edc 4513 Request Representation: EndDeviceControl 4514 Response Representation: EndDeviceControlList 4515 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Discouraged, DELETE: Error 4516
14.3.3.5 EndDeviceControl Resource 4517
Specific EndDeviceControl resource. This resource can be thought of as a particular Demand Response / 4518 Load Control event for a period of time. 4519
Sample URI: /dr/{id1}/edc/{id2} 4520 Request Representation: EndDeviceControl 4521 Response Representation: EndDeviceControl 4522 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Discouraged 4523
14.3.3.6 LoadShedAvailability Resource 4524
Allows clients to expose their load shed availability. 4525
Sample URI: /edev/{id1}/lsa 4526 Request Representation: LoadShedAvailability 4527 Response Representation: LoadShedAvailability 4528 Methods: GET/HEAD: Mandatory, PUT: Mandatory, POST: Error, DELETE: Optional 4529
14.3.4 Metering Function Set 4530
14.3.4.1 UsagePointList Resource 4531
Usage point resource list. Devices implementing the UsagePointList resource MAY support multiple 4532 instances of usage points. 4533
Sample URI: /upt 4534 Request Representation: UsagePoint 4535 Response Representation: UsagePointList 4536 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Optional, DELETE: Error 4537
14.3.4.2 UsagePoint Resource 4538
Usage point instance including links to associated information. 4539
Sample URI: /upt/{id1} 4540 Request Representation: UsagePoint 4541 Response Representation: UsagePoint 4542 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Optional 4543
14.3.4.3 MeterReadingList Resource 4544
Meter Reading list including explicit URIs for each valid meter reading resource. 4545
Sample URI: /upt/{id1}/mr 4546 Request Representation: MeterReading 4547
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 143 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Response Representation: MeterReadingList 4548 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Optional, DELETE: Error 4549
14.3.4.4 MeterReading Resource 4550
Meter Reading instance which contains ReadingSet and Reading resources 4551
Sample URI: /upt/{id1}/mr/{id2} 4552 Request Representation: MeterReading 4553 Response Representation: MeterReading 4554 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Optional 4555
14.3.4.5 ReadingType Resource 4556
Meter Reading type 4557
Sample URI: /upt/{id1}/mr/{id2}/rt 4558 Request Representation: ReadingType 4559 Response Representation: ReadingType 4560 Methods: GET/HEAD: Mandatory, PUT: Optional, POST: Error, DELETE: Error 4561
14.3.4.6 ReadingSetList Resource 4562
Reading Set list 4563
Sample URI: /upt/{id1}/mr/{id2}/rs 4564 Request Representation: ReadingSet 4565 Response Representation: ReadingSetList 4566 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Optional, DELETE: Error 4567
14.3.4.7 ReadingSet Resource 4568
Reading Set instance which contains a list of Reading(s) 4569
Sample URI: /upt/{id1}/mr/{id2}/rs/{id3} 4570 Request Representation: ReadingSet 4571 Response Representation: ReadingSet 4572 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Optional 4573
14.3.4.8 ReadingList Resource 4574
Reading list of a particular meter reading set. 4575
Sample URI: /upt/{id1}/mr/{id2}/rs/{id3}/r 4576 Request Representation: Reading 4577 Response Representation: ReadingList 4578 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Optional, DELETE: Error 4579
14.3.4.9 Reading Resource 4580
Reading instance of a particular meter reading type. 4581
Sample URI: /upt/{id1}/mr/{id2}/rs/{id3}/r/{id4} 4582 Request Representation: Reading 4583 Response Representation: Reading 4584 Methods: GET/HEAD: Mandatory, PUT: Optional, POST: Error, DELETE: Optional 4585
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 144 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
14.3.4.10 MirrorUsagePointList Resource 4586
Mirror Usage point (meter) resource list. Devices implementing the MirrorUsagePointList resource may 4587 support multiple instances of meter mirror asset. 4588
Sample URI: /mup 4589 Request Representation: MirrorUsagePoint 4590 Response Representation: MirrorUsagePointList 4591 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Mandatory, DELETE: Error 4592
14.3.4.11 MirrorUsagePoint Resource 4593
Mirror Usage point instance including resources it supports. 4594
Sample URI: /mup/{id1} 4595 Request Representation: MirrorUsagePoint (PUT), MirrorMeterReading (POST), MirrorMeterReadingList 4596 (POST) 4597 Response Representation: MirrorUsagePoint 4598 Methods: GET/HEAD: Optional, PUT: Mandatory, POST: Mandatory, DELETE: Mandatory 4599
14.3.5 Pricing Function Set 4600
14.3.5.1 TariffProfileList Resource 4601
List of TariffProfile instances. 4602
Sample URI: /tp 4603 Request Representation: TariffProfile 4604 Response Representation: TariffProfileList 4605 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Discouraged, DELETE: Error 4606
14.3.5.2 TariffProfile Resource 4607
Specific TariffProfile instance. Allows clients to obtain information about the rate code. 4608
Sample URI: /tp/{id1} 4609 Request Representation: TariffProfile 4610 Response Representation: TariffProfile 4611 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Discouraged 4612
14.3.5.3 RateComponentList Resource 4613
List of RateComponent instances. This list specifies a rate-specific container for the charges associated 4614 with a specific ReadingType, also referenced by the Metering function set. 4615
Sample URI: /tp/{id1}/rc 4616 Request Representation: RateComponent 4617 Response Representation: RateComponentList 4618 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Discouraged, DELETE: Error 4619
14.3.5.4 RateComponent Resource 4620
Specific RateComponent instance. Includes link(s) to the list of TimeTariffIntervals that apply to 4621 referenced ReadingType for the RateComponent instance. 4622
Sample URI: /tp/{id1}/rc/{id2} 4623 Request Representation: RateComponent 4624
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 145 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Response Representation: RateComponent 4625 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Discouraged 4626
14.3.5.5 ActiveTimeTariffIntervalList Resource 4627
The active TimeTariffInterval instance(s) for a particular TariffProfile. 4628
Sample URI: /tp/{id1}/rc/{id2}/acttti 4629 Request Representation: TimeTariffInterval 4630 Response Representation: TimeTariffIntervalList 4631 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Error 4632
14.3.5.6 TimeTariffIntervalList Resource 4633
Collection of TimeTariffInterval instances, including associated ConsumptionTariffInterval. 4634
Sample URI: /tp/{id1}/rc/{id2}/tti 4635 Request Representation: TimeTariffInterval 4636 Response Representation: TimeTariffIntervalList 4637 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Discouraged, DELETE: Error 4638
14.3.5.7 TimeTariffInterval Resource 4639
Specific TimeTariffInterval instance that represents a unique usage interval and associated charges for the 4640 premises. 4641
Sample URI: /tp/{id1}/rc/{id2}/tti/{id3} 4642 Request Representation: TimeTariffInterval 4643 Response Representation: TimeTariffInterval 4644 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Discouraged 4645
14.3.5.8 ConsumptionTariffIntervalList Resource 4646
List of ConsumptionTariffInterval instances. 4647
Sample URI: /tp/{id1}/rc/{id2}/tti/{id3}/cti 4648 Request Representation: ConsumptionTariffInterval 4649 Response Representation: ConsumptionTariffIntervalList 4650 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Discouraged, DELETE: Error 4651
14.3.5.9 ConsumptionTariffInterval Resource 4652
Specific ConsumptionTariffInterval instance. 4653
Sample URI: /tp/{id1}/rc/{id2}/tti/{id3}/cti/{id4} 4654 Request Representation: ConsumptionTariffInterval 4655 Response Representation: ConsumptionTariffInterval 4656 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Discouraged 4657
14.3.6 Messaging Function Set 4658
14.3.6.1 MessagingProgramList Resource 4659
List of MessagingProgram instances or channels. Devices implementing the /msg resource MAY support 4660 multiple instances of MessagingProgram 4661
Sample URI: /msg 4662 Request Representation: MessagingProgram 4663
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 146 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Response Representation: MessagingProgramList 4664 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Discouraged, DELETE: Error 4665
14.3.6.2 MessagingProgram Resource 4666
Specific MessagingProgram instance. This resource can be thought of as a particular TextMessageList or 4667 channel. 4668
Sample URI: /msg/{id1} 4669 Request Representation: MessagingProgram 4670 Response Representation: MessagingProgram 4671 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Discouraged 4672
14.3.6.3 ActiveTextMessageList Resource 4673
List of Messages that are currently active. 4674
Sample URI: /msg/{id1}/acttxt 4675 Request Representation: TextMessage 4676 Response Representation: TextMessageList 4677 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Error 4678
14.3.6.4 TextMessageList Resource 4679
A list of TextMessages. 4680
Sample URI: /msg/{id1}/txt 4681 Request Representation: TextMessage 4682 Response Representation: TextMessageList 4683 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Discouraged, DELETE: Error 4684
14.3.6.5 TextMessage Resource 4685
An individual TextMessage. 4686
Sample URI: /msg/{id1}/txt/{id2} 4687 Request Representation: TextMessage 4688 Response Representation: TextMessage 4689 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Discouraged 4690
14.3.7 Billing Function Set 4691
14.3.7.1 CustomerAccountList Resource 4692
A List of customer accounts 4693
Sample URI: /bill 4694 Request Representation: CustomerAccount 4695 Response Representation: CustomerAccountList 4696 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Discouraged, DELETE: Error 4697
14.3.7.2 CustomerAccount Resource 4698
Customer account information 4699
Sample URI: /bill/{id1} 4700 Request Representation: CustomerAccount 4701 Response Representation: CustomerAccount 4702
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 147 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Discouraged 4703
14.3.7.3 CustomerAgreementList Resource 4704
A list of customer agreements 4705
Sample URI: /bill/{id1}/ca 4706 Request Representation: CustomerAgreement 4707 Response Representation: CustomerAgreementList 4708 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Discouraged, DELETE: Error 4709
14.3.7.4 CustomerAgreement Resource 4710
A customer agreement 4711
Sample URI: /bill/{id1}/ca/{id2} 4712 Request Representation: CustomerAgreement 4713 Response Representation: CustomerAgreement 4714 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Discouraged 4715
14.3.7.5 ActiveBillingPeriodList Resource 4716
A list of active billing periods. 4717
Sample URI: /bill/{id1}/ca/{id2}/actbp 4718 Request Representation: BillingPeriod 4719 Response Representation: BillingPeriodList 4720 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Error 4721
14.3.7.6 BillingPeriodList Resource 4722
List of BillingPeriods 4723
Sample URI: /bill/{id1}/ca/{id2}/bp 4724 Request Representation: BillingPeriod 4725 Response Representation: BillingPeriodList 4726 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Discouraged, DELETE: Error 4727
14.3.7.7 BillingPeriod Resource 4728
Specific Billing Period information 4729
Sample URI: /bill/{id1}/ca/{id2}/bp/{id3} 4730 Request Representation: BillingPeriod 4731 Response Representation: BillingPeriod 4732 Methods: GET/HEAD: Mandatory, PUT: Discouraged, POST: Error, DELETE: Discouraged 4733
14.3.7.8 ProjectionReadingList Resource 4734
A list of reading projections. 4735
Sample URI: /bill/{id1}/ca/{id2}/pro 4736 Request Representation: ProjectionReading 4737 Response Representation: ProjectionReadingList 4738 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Discouraged, DELETE: Error 4739
14.3.7.9 ProjectionReading Resource 4740
A specific projection reading channel 4741
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 148 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Sample URI: /bill/{id1}/ca/{id2}/pro/{id3} 4742 Request Representation: ProjectionReading 4743 Response Representation: ProjectionReading 4744 Methods: GET/HEAD: Mandatory, PUT: Discouraged, POST: Error, DELETE: Discouraged 4745
14.3.7.10 BillingReadingSetList Resource 4746
A list of billing reading sets 4747
Sample URI: /brs 4748 Request Representation: BillingReadingSet 4749 Response Representation: BillingReadingSetList 4750 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Discouraged, DELETE: Error 4751
14.3.7.11 BillingReadingSet Resource 4752
A specific billing reading set 4753
Sample URI: /brs/{id1} 4754 Request Representation: BillingReadingSet 4755 Response Representation: BillingReadingSet 4756 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Discouraged 4757
14.3.7.12 BillingReadingList Resource 4758
A list of billing readings 4759
Sample URI: /brs/{id1}/br 4760 Request Representation: BillingReading 4761 Response Representation: BillingReadingList 4762 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Discouraged, DELETE: Error 4763
14.3.7.13 BillingReading Resource 4764
A specific billing reading 4765
Sample URI: /brs/{id1}/br/{id2} 4766 Request Representation: BillingReading 4767 Response Representation: BillingReading 4768 Methods: GET/HEAD: Mandatory, PUT: Discouraged, POST: Error, DELETE: Discouraged 4769
14.3.7.14 TargetReadingList Resource 4770
A list of billing targets. 4771
Sample URI: /bill/{id1}/ca/{id2}/tar 4772 Request Representation: TargetReading 4773 Response Representation: TargetReadingList 4774 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Discouraged, DELETE: Error 4775
14.3.7.15 TargetReading Resource 4776
A specific target reading channel 4777
Sample URI: /bill/{id1}/ca/{id2}/tar/{id3} 4778 Request Representation: TargetReading 4779 Response Representation: TargetReading 4780
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 149 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Discouraged 4781
14.3.7.16 HistoricalReadingList Resource 4782
A list of verified historical readings. 4783
Sample URI: /bill/{id1}/ca/{id2}/ver 4784 Request Representation: HistoricalReading 4785 Response Representation: HistoricalReadingList 4786 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Discouraged, DELETE: Error 4787
14.3.7.17 HistoricalReading Resource 4788
A specific historical reading channel 4789
Sample URI: /bill/{id1}/ca/{id2}/ver/{id3} 4790 Request Representation: HistoricalReading 4791 Response Representation: HistoricalReading 4792 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Discouraged 4793
14.3.7.18 ServiceSupplier Resource 4794
A specific service supplier 4795
Sample URI: /bill/{id1}/ss 4796 Request Representation: ServiceSupplier 4797 Response Representation: ServiceSupplier 4798 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Discouraged 4799
14.3.8 Prepayment Function Set 4800
14.3.8.1 PrepaymentList Resource 4801
A List of Prepayment instances. 4802
Sample URI: /ppy 4803 Request Representation: Prepayment 4804 Response Representation: PrepaymentList 4805 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Discouraged, DELETE: Error 4806
14.3.8.2 Prepayment Resource 4807
A particular Prepayment instance. Provides links to the Account Balance, Credit Register, and Operation 4808 Status resources for a particular service. 4809
Sample URI: /ppy/{id1} 4810 Request Representation: Prepayment 4811 Response Representation: Prepayment 4812 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Discouraged 4813
14.3.8.3 AccountBalance Resource 4814
Account Balance instance. 4815
Sample URI: /ppy/{id1}/ab 4816 Request Representation: AccountBalance 4817 Response Representation: AccountBalance 4818 Methods: GET/HEAD: Mandatory, PUT: Discouraged, POST: Error, DELETE: Error 4819
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 150 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
14.3.8.4 PrepayOperationStatus Resource 4820
The Operation Status for the given service. Identifies whether service should be continued. MAY also 4821 include other status information, such as low credit warning. 4822
Sample URI: /ppy/{id1}/os 4823 Request Representation: PrepayOperationStatus 4824 Response Representation: PrepayOperationStatus 4825 Methods: GET/HEAD: Mandatory, PUT: Discouraged, POST: Error, DELETE: Error 4826
14.3.8.5 ActiveSupplyInterruptionOverrideList Resource 4827
A list of active supply interruption overrides 4828
Sample URI: /ppy/{id1}/actsi 4829 Request Representation: SupplyInterruptionOverride 4830 Response Representation: SupplyInterruptionOverrideList 4831 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Error 4832
14.3.8.6 SupplyInterruptionOverrideList Resource 4833
A List of Supply Interruption Override instances. 4834
Sample URI: /ppy/{id1}/si 4835 Request Representation: SupplyInterruptionOverride 4836 Response Representation: SupplyInterruptionOverrideList 4837 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Discouraged, DELETE: Error 4838
14.3.8.7 SupplyInterruptionOverride Resource 4839
A particular Supply Interruption Override instance. This defines a period of time during which supply 4840 would not be interrupted even if available credit has been exhausted. 4841
Sample URI: /ppy/{id1}/si/{id2} 4842 Request Representation: SupplyInterruptionOverride 4843 Response Representation: SupplyInterruptionOverride 4844 Methods: GET/HEAD: Mandatory, PUT: Discouraged, POST: Error, DELETE: Discouraged 4845
14.3.8.8 CreditRegisterList Resource 4846
A List of Credit Register instances. Interface for new credit transactions. 4847
Sample URI: /ppy/{id1}/cr 4848 Request Representation: CreditRegister 4849 Response Representation: CreditRegisterList 4850 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Optional, DELETE: Error 4851
14.3.8.9 CreditRegister Resource 4852
A particular Credit Register instance. Records a payment transaction or other credit addition. 4853
Sample URI: /ppy/{id1}/cr/{id2} 4854 Request Representation: CreditRegister 4855 Response Representation: CreditRegister 4856 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Optional 4857
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 151 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
14.3.9 Flow Reservation Function Set 4858
14.3.9.1 FlowReservationRequestList Resource 4859
List of FlowReservationRequests. Devices implementing the FlowReservationRequestList resource 4860 MAY support multiple FlowReservationRequests. 4861
Sample URI: /edev/{id1}/frq 4862 Request Representation: FlowReservationRequest 4863 Response Representation: FlowReservationRequestList 4864 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Mandatory, DELETE: Error 4865
14.3.9.2 FlowReservationRequest Resource 4866
Specific FlowReservationRequest resource. This resource can be thought of as a particular reservation 4867 event request for fast charging or discharging over a period of time. 4868
Sample URI: /edev/{id1}/frq/{id2} 4869 Request Representation: FlowReservationRequest 4870 Response Representation: FlowReservationRequest 4871 Methods: GET/HEAD: Mandatory, PUT: Mandatory, POST: Error, DELETE: Optional 4872
14.3.9.3 FlowReservationResponseList Resource 4873
List of FlowReservationResponses. Devices implementing the FlowReservationResponseList resource 4874 MAY support multiple FlowReservationResponses. 4875
Sample URI: /edev/{id1}/frp 4876 Request Representation: FlowReservationResponse 4877 Response Representation: FlowReservationResponseList 4878 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Discouraged, DELETE: Error 4879
14.3.9.4 FlowReservationResponse Resource 4880
Specific FlowReservationResponse resource. This resource can be thought of as a particular reservation 4881 event response for fast charging or discharging over a period of time. 4882
Sample URI: /edev/{id1}/frp/{id2} 4883 Request Representation: FlowReservationResponse 4884 Response Representation: FlowReservationResponse 4885 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Discouraged 4886
14.3.10 Distributed Energy Resources Function Set 4887
14.3.10.1 DERList Resource 4888
A list of Distributed Energy Resources 4889
Sample URI: /edev/{id1}/der 4890 Request Representation: DER 4891 Response Representation: DERList 4892 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Optional, DELETE: Error 4893
14.3.10.2 DER Resource 4894
The information about a specific Distributed Energy Resource. 4895
Sample URI: /edev/{id1}/der/{id2} 4896
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 152 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Request Representation: DER 4897 Response Representation: DER 4898 Methods: GET/HEAD: Mandatory, PUT: Optional, POST: Error, DELETE: Optional 4899
14.3.10.3 AssociatedUsagePoint Resource 4900
The usage point associated with this DER instance. 4901
Sample URI: /edev/{id1}/der/{id2}/upt 4902 Request Representation: UsagePoint 4903 Response Representation: UsagePoint 4904 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Optional 4905
14.3.10.4 AssociatedDERProgramList Resource 4906
The List of DERProgram instances associated with this DER. 4907
Sample URI: /edev/{id1}/der/{id2}/derp 4908 Request Representation: DERProgram 4909 Response Representation: DERProgramList 4910 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Optional, DELETE: Error 4911
14.3.10.5 CurrentDERProgram Resource 4912
The specific DER Control Program being followed by the DER. 4913
Sample URI: /edev/{id1}/der/{id2}/cdp 4914 Request Representation: DERProgram 4915 Response Representation: DERProgram 4916 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Optional 4917
14.3.10.6 DERSettings Resource 4918
The DER settings of the associated EndDevice or SelfDevice. 4919
Sample URI: /edev/{id1}/der/{id2}/derg 4920 Request Representation: DERSettings 4921 Response Representation: DERSettings 4922 Methods: GET/HEAD: Mandatory, PUT: Mandatory, POST: Error, DELETE: Error 4923
14.3.10.7 DERStatus Resource 4924
The DER status of the associated EndDevice or SelfDevice. 4925
Sample URI: /edev/{id1}/der/{id2}/ders 4926 Request Representation: DERStatus 4927 Response Representation: DERStatus 4928 Methods: GET/HEAD: Mandatory, PUT: Mandatory, POST: Error, DELETE: Error 4929
14.3.10.8 DERAvailability Resource 4930
The DER availability of the associated EndDevice or SelfDevice. 4931
Sample URI: /edev/{id1}/der/{id2}/dera 4932 Request Representation: DERAvailability 4933 Response Representation: DERAvailability 4934 Methods: GET/HEAD: Mandatory, PUT: Mandatory, POST: Error, DELETE: Error 4935
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 153 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
14.3.10.9 DERCapability Resource 4936
Capabilities of the DER 4937
Sample URI: /edev/{id1}/der/{id2}/dercap 4938 Request Representation: DERCapability 4939 Response Representation: DERCapability 4940 Methods: GET/HEAD: Mandatory, PUT: Mandatory, POST: Error, DELETE: Error 4941
14.3.10.10 DERProgramList Resource 4942
List of DERProgram instances. Devices implementing the DERProgramList resource MAY support 4943 multiple instances of DERPrograms. 4944
Sample URI: /derp 4945 Request Representation: DERProgram 4946 Response Representation: DERProgramList 4947 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Optional, DELETE: Error 4948
14.3.10.11 DERProgram Resource 4949
Specific DER Control Program collection resource. This resource can be thought of as a particular 4950 DERProgram endpoint. This representation contains simple management attributes, as well as each 4951 associated resource. 4952
Sample URI: /derp/{id1} 4953 Request Representation: DERProgram 4954 Response Representation: DERProgram 4955 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Optional 4956
14.3.10.12 ActiveDERControlList Resource 4957
List of DERControls that are currently active. 4958
Sample URI: /derp/{id1}/actderc 4959 Request Representation: DERControl 4960 Response Representation: DERControlList 4961 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Error 4962
14.3.10.13 DERControlList Resource 4963
List of DERControls. Devices implementing the DERControlList resource MAY support multiple 4964 DERControls. 4965
Sample URI: /derp/{id1}/derc 4966 Request Representation: DERControl 4967 Response Representation: DERControlList 4968 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Optional, DELETE: Error 4969
14.3.10.14 DERControl Resource 4970
Specific DERControl resource. This resource can be thought of as a particular DER control event for a 4971 period of time. 4972
Sample URI: /derp/{id1}/derc/{id2} 4973 Request Representation: DERControl 4974 Response Representation: DERControl 4975
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 154 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Optional 4976
14.3.10.15 DefaultDERControl Resource 4977
The DefaultDERControl resource. This resource can be thought of as the default DERControl to be used 4978 if no active DERControl event is found. 4979
Sample URI: /derp/{id1}/dderc 4980 Request Representation: DefaultDERControl 4981 Response Representation: DefaultDERControl 4982 Methods: GET/HEAD: Mandatory, PUT: Optional, POST: Error, DELETE: Error 4983
14.3.10.16 DERCurveList Resource 4984
A List of DER curves 4985
Sample URI: /derp/{id1}/dc 4986 Request Representation: DERCurve 4987 Response Representation: DERCurveList 4988 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Optional, DELETE: Error 4989
14.3.10.17 DERCurve Resource 4990
A DER curve instance 4991
Sample URI: /derp/{id1}/dc/{id2} 4992 Request Representation: DERCurve 4993 Response Representation: DERCurve 4994 Methods: GET/HEAD: Mandatory, PUT: Error, POST: Error, DELETE: Optional 4995
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 155 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
15 Appendix B – SEP 2 Model (INFORMATIVE) 4996
Note that the XML version of the model, contained in the XML Schema definition "sep.xsd" contained in 4997 [ZB 13-0201] is normative. This section presents a human-friendly view of the information to facilitate 4998 comments on the content. 4999
15.1 SEP 2 Package 5000
The Smart Energy Profile 2.0 model is organized into function sets, represented by sub-packages. 5001 However, all structures are defined inside a single namespace. 5002
5003
Figure 15-1: Version Information 5004
15.1.1 DeviceCapability Package 5005
Contains definition of the objects used to convey the resources that are implemented by the publishing 5006 host. 5007
5008
Figure 15-2: DeviceCapability 5009
class Version Information
SEP 2.0
tagsdefaultNamespace = http://zigbee.org/sepelementFormDefault = qualifiedschemaLocation = sep.xsdtargetNamespace = http://zigbee.org/septrace_id = version = 2.0.0
class Dev iceCapability
Dev iceCapabilityListLink
EndDev iceListLink
ResourceFunctionSetAssignmentsBase
«XSDattribute»::Resource+ href :anyURI [0..1]
Making DeviceCapability inherit from FunctionSetAssignments allows those group resources to be published with or without use of FunctionSetAssignments.
ListLinkMirrorUsagePointListLink
LinkSelfDev iceLink
0..10..10..1
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 156 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
DeviceCapability Object (FunctionSetAssignmentsBase) 5010 Returned by the URI provided by DNS-SD, to allow clients to find the URIs to the resources in 5011 which they are interested. 5012
15.1.2 Common Package 5013
This package contains objects that are used in multiple function sets. 5014
15.1.2.1 Identification Package 5015
Contains super-classes that define the attributes common to categories of objects. 5016
5017
Figure 15-3: Identification 5018
IdentifiedObject Object (Resource) 5019 This is a root class to provide common naming attributes for all classes needing naming attributes 5020
description attribute (String32) [0..1] 5021 The description is a human readable text describing or naming the object. 5022
mRID attribute (mRIDType) 5023 The global identifier of the object. 5024
version attribute (VersionType) [0..1] 5025 Contains the version number of the object. See the type definition for details. 5026
Link Object () 5027 Links provide a reference, via URI, to another resource. 5028
href attribute (anyURI) «XSDattribute» 5029 A URI reference. 5030
List Object (Resource) 5031 Container to hold a collection of object instances or references. See [ZB 11-0167] Design 5032 Patterns section for additional details. 5033
class Identification
List
«XSDattribute»+ all :UInt16+ results :UInt8
Resource
«XSDattribute»+ href :anyURI [0..1]
IdentifiedObject
+ description :String32 [0..1]+ mRID :mRIDType+ version :VersionType [0..1] = 0
Link
«XSDattribute»+ href :anyURI
ListLink
«XSDattribute»+ all :UInt16
SubscribableIdentifiedObject
+ description :String32 [0..1]+ mRID :mRIDType+ version :VersionType [0..1] = 0
RespondableIdentifiedObject
+ description :String32 [0..1]+ mRID :mRIDType+ version :VersionType [0..1] = 0
RespondableResource
«XSDattribute»+ replyTo :anyURI [0..1]+ responseRequired :HexBinary8 [0..1] = 00
SubscribableList
«XSDattribute»+ all :UInt16+ results :UInt8
SubscribableResource
«XSDattribute»+ subscribable :SubscribableType [0..1] = 0
RespondableSubscribableIdentifiedObject
+ description :String32 [0..1]+ mRID :mRIDType+ version :VersionType [0..1] = 0
«XSDattribute»+ subscribable :SubscribableType [0..1] = 0
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 157 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
all attribute (UInt16) «XSDattribute» 5034 The number specifying "all" of the items in the list. Required on a response to a GET, ignored otherwise. 5035
results attribute (UInt8) «XSDattribute» 5036 Indicates the number of items in this page of results. 5037
ListLink Object (Link) 5038 ListLinks provide a reference, via URI, to a List. 5039
all attribute (UInt16) «XSDattribute» 5040 Indicates the total number of items in the referenced list. 5041
Resource Object () 5042 A resource is an addressable unit of information, either a collection (List) or instance of an object 5043 (identifiedObject, or simply, Resource) 5044
href attribute (anyURI) [0..1] «XSDattribute» 5045 A reference to the resource address (URI). Required in a response to a GET, ignored otherwise. 5046
RespondableIdentifiedObject Object (RespondableResource) 5047 An IdentifiedObject to which a Response can be requested. 5048
description attribute (String32) [0..1] 5049 The description is a human readable text describing or naming the object. 5050
mRID attribute (mRIDType) 5051 The global identifier of the object. 5052
version attribute (VersionType) [0..1] 5053 Contains the version number of the object. See the type definition for details. 5054
RespondableResource Object (Resource) 5055 A Resource to which a Response can be requested. 5056
replyTo attribute (anyURI) [0..1] «XSDattribute» 5057 A reference to the response resource address (URI). Required on a response to a GET if responseRequired 5058 is "true". 5059
responseRequired attribute (HexBinary8) [0..1] «XSDattribute» 5060 Indicates whether or not a response is required upon receipt, creation or update of this resource. 5061 Responses shall be posted to the collection specified in "replyTo". 5062
If the resource has a deviceCategory field, devices that match one or more of the device types indicated in 5063 deviceCategory SHALL respond according to the rules listed below. If the category does not match, the 5064 device SHALL NOT respond. If the resource does not have a deviceCategory field, a device receiving the 5065 resource SHALL respond according to the rules listed below. 5066
Value encoded as hex according to the following bit assignments, any combination is possible. 5067
See Table 10-10 for the list of appropriate Response status codes to be sent for these purposes. 5068
0 - End device shall indicate that message was received 5069
1 - End device shall indicate specific response. 5070
2 - End user / customer response is required. 5071
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 158 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
All other values reserved. 5072
RespondableSubscribableIdentifiedObject Object (RespondableResource) 5073 An IdentifiedObject to which a Response can be requested. 5074
description attribute (String32) [0..1] 5075 The description is a human readable text describing or naming the object. 5076
mRID attribute (mRIDType) 5077 The global identifier of the object. 5078
subscribable attribute (SubscribableType) [0..1] «XSDattribute» 5079 Indicates whether or not subscriptions are supported for this resource, and whether or not conditional 5080 (thresholds) are supported. If not specified, is "not subscribable" (0). 5081
version attribute (VersionType) [0..1] 5082 Contains the version number of the object. See the type definition for details. 5083
SubscribableIdentifiedObject Object (SubscribableResource) 5084 An IdentifiedObject to which a Subscription can be requested. 5085
description attribute (String32) [0..1] 5086 The description is a human readable text describing or naming the object. 5087
mRID attribute (mRIDType) 5088 The global identifier of the object. 5089
version attribute (VersionType) [0..1] 5090 Contains the version number of the object. See the type definition for details. 5091
SubscribableList Object (SubscribableResource) 5092 A List to which a Subscription can be requested. 5093
all attribute (UInt16) «XSDattribute» 5094 The number specifying "all" of the items in the list. Required on GET, ignored otherwise. 5095
results attribute (UInt8) «XSDattribute» 5096 Indicates the number of items in this page of results. 5097
SubscribableResource Object (Resource) 5098 A Resource to which a Subscription can be requested. 5099
subscribable attribute (SubscribableType) [0..1] «XSDattribute» 5100 Indicates whether or not subscriptions are supported for this resource, and whether or not conditional 5101 (thresholds) are supported. If not specified, is "not subscribable" (0). 5102
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 159 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
15.1.2.2 Objects Package 5103
Contains definitions of objects used by multiple function sets. 5104
5105
Figure 15-4: Events 5106
5107
Figure 15-5: Programs 5108
class Ev ents
Ev ent
+ creationTime :TimeType+ interval :DateTimeInterval
TextMessage
+ originator :String20 [0..1]+ priority :PriorityType+ textMessage :string
EndDev iceControl
+ deviceCategory :DeviceCategoryType+ drProgramMandatory :boolean+ loadShiftForward :boolean+ overrideDuration :UInt16 [0..1] = 0
TimeTariffInterv al
+ touTier :TOUType
Ev entStatus
+ currentStatus :UInt8+ dateTime :TimeType+ potentiallySuperseded :boolean+ potentiallySupersededTime :TimeType [0..1]+ reason :String192 [0..1]
RandomizableEv ent
+ randomizeDuration :OneHourRangeType [0..1] = 0+ randomizeStart :OneHourRangeType [0..1] = 0
AbstractFlowReserv ationDERControl
RespondableResourceRespondableSubscribableIdentifiedObject
+ description :String32 [0..1]+ mRID :mRIDType+ version :VersionType [0..1] = 0
«XSDattribute»+ subscribable :SubscribableType [0..1] = 0
1
class Programs
UInt8PrimacyType
notesValues possible for indication of "Primary" provider:
0: In home energy management system1: Contracted premises service provider2: Non-contractual service providerAll other values reserved.
IdentifiedObjectDemandResponseProgram
+ availabil ityUpdatePercentChangeThreshold :PerCent [0..1] = 0+ availabil ityUpdatePowerChangeThreshold :ActivePower [0..1] = 0+ primacy :PrimacyType
IdentifiedObjectDERProgram
+ primacy :PrimacyType
SubscribableIdentifiedObjectMessagingProgram
+ locale :LocaleType+ primacy :PrimacyType
IdentifiedObjectTariffProfile
+ currency :CurrencyCode [0..1]+ pricePowerOfTenMultiplier :PowerOfTenMultiplierType [0..1]+ primacy :PrimacyType+ rateCode :String20 [0..1]+ serviceCategoryKind :ServiceKind
UInt8PriorityType
notesIndicates the priority of a message:0 - Low1 - Normal2 - High3 - CriticalAll other values reserved.
EventTextMessage
+ originator :String20 [0..1]+ priority :PriorityType+ textMessage :string
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 160 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
5109
Figure 15-6: Error 5110
5111
Error Object () 5112 Contains information about the nature of an error if a request could not be completed 5113 successfully. 5114
maxRetryDuration attribute (UInt16) [0..1] 5115 Contains the number of seconds the client SHOULD wait before retrying the request. 5116
reasonCode attribute (UInt16) 5117 Code indicating the reason for failure. 5118
0 - Invalid request format 5119
1 - Invalid request values (e.g. invalid threshold values) 5120
2 - Resource limit reached 5121
3 - Conditional subscription field not supported 5122
4 - Maximum request frequency exceeded 5123
All other values reserved 5124
Event Object (RespondableSubscribableIdentifiedObject) 5125 An Event indicates information that applies to a particular period of time. Events SHALL be 5126 executed relative to the time of the server, as described in the Time function set section 11.1. 5127
creationTime attribute (TimeType) 5128 The time at which the Event was created. 5129
interval attribute (DateTimeInterval) 5130 The period during which the Event applies. 5131
EventStatus Object () 5132 Current status information relevant to a specific object. The Status object is used to indicate the 5133 current status of an Event. Devices can read the containing resource (e.g. TextMessage) to get the 5134 most up to date status of the event. Devices can also subscribe to a specific resource instance to 5135 get updates when any of its attributes change, including the Status object. 5136
currentStatus attribute (UInt8) 5137
class Error
Error
+ maxRetryDuration :UInt16 [0..1]+ reasonCode :UInt16
reasonCodeCode indicating the reason for failure.
0 - Invalid request format1 - Invalid request values (e.g. invalid threshold values)2 - Resource l imit reached3 - Conditional subscription field not supported4 - Maximum request frequency exceededAll other values reserved
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 161 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Field representing the current status type. 5138
0 = Scheduled 5139
This status indicates that the event has been scheduled and the event has not yet started. The server 5140 SHALL set the event to this status when the event is first scheduled and persist until the event has become 5141 active or has been cancelled. For events with a start time less than or equal to the current time, this status 5142 SHALL never be indicated, the event SHALL start with a status of “Active”. 5143
1 = Active 5144
This status indicates that the event is currently active. The server SHALL set the event to this status when 5145 the event reaches its earliest Effective Start Time. 5146
2 = Cancelled 5147
When events are cancelled, the Status.dateTime attribute SHALL be set to the time the cancellation 5148 occurred, which cannot be in the future. The server is responsible for maintaining the cancelled event in 5149 its collection for the duration of the original event, or until the server has run out of space and needs to 5150 store a new event. Client devices SHALL be aware of Cancelled events, determine if the Cancelled event 5151 applies to them, and cancel the event immediately if applicable. 5152
3 = Cancelled with Randomization 5153
The server is responsible for maintaining the cancelled event in its collection for the duration of the 5154 Effective Scheduled Period. Client devices SHALL be aware of Cancelled with Randomization events, 5155 determine if the Cancelled event applies to them, and cancel the event immediately, using the larger of 5156 (absolute value of randomizeStart) and (absolute value of randomizeDuration) as the end randomization, 5157 in seconds. This Status.type SHALL NOT be used with "regular" Events, only with specializations of 5158 RandomizableEvent. 5159
4 = Superseded 5160
Events marked as Superseded by servers are events that may have been replaced by new events that target 5161 the same group of device types and overlap for a given period of time. Servers SHALL mark an event as 5162 Superseded at the earliest Effective Start Time of the overlapping event. Servers are responsible for 5163 maintaining the Superseded event in their collection for the duration of the Effective Scheduled Period. 5164
Client devices encountering a Superseded event SHALL terminate execution of the event immediately 5165 and commence execution of the new event immediately, unless the current time is within the start 5166 randomization window of the superseded event, in which case the client SHALL obey the start 5167 randomization of the new event. This Status.type SHALL NOT be used with TextMessage, since multiple 5168 text messages can be active. 5169
All other values reserved. 5170
dateTime attribute (TimeType) 5171 The dateTime attribute will provide a timestamp of when the current status was defined. dateTime MUST 5172 be set to the time at which the status change occurred, not a time in the future or past. 5173
potentiallySuperseded attribute (boolean) 5174 Set to true by a server of this event if there are events that may overlap this event in time and also overlap 5175 in DeviceCategory on the same function set instance. SHALL NOT be set to true if the event is a 5176 TextMessage. 5177
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 162 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
potentiallySupersededTime attribute (TimeType) [0..1] 5178 Indicates the time that the potentiallySuperseded flag was set. 5179
reason attribute (String192) [0..1] 5180 The Reason attribute allows a Service provider to provide a textual explanation of the status. 5181
RandomizableEvent Object (Event) 5182 An Event that can indicate time ranges over which the start time and duration SHALL be 5183 randomized. 5184
randomizeDuration attribute (OneHourRangeType) [0..1] 5185 Number of seconds boundary inside which a random value must be selected to be applied to the 5186 associated interval duration, to avoid sudden synchronized demand changes. If related to price level 5187 changes, sign may be ignored. Valid range is -3600 to 3600. If not specified, 0 is the default. 5188
randomizeStart attribute (OneHourRangeType) [0..1] 5189 Number of seconds boundary inside which a random value must be selected to be applied to the 5190 associated interval start time, to avoid sudden synchronized demand changes. If related to price level 5191 changes, sign may be ignored. Valid range is -3600 to 3600. If not specified, 0 is the default. 5192
15.1.2.3 Types Package 5193
Contains definitions of reusable data types. 5194
5195
Figure 15-7: Types 5196
class Types
unsignedByte
«XSDsimple...UInt8
Dev iceCategoryType
UnitType
hexBinary
«XSDsimple...HexBinary32
PriorityType
AccumulationBehav iourType
DataQualifierType
TOUType
ConsumptionBlockType
FlowDirectionType
CommodityType
KindType
PowerOfTenMultiplierType
UomType
byte
«XSDsimple...Int8
PhaseCode
CurrencyCode
unsignedShort
«XSDsimple...UInt16
Serv iceKind
ChargeKind
TimeOffsetType
int
«XSDsimple...Int32
short
«XSDsimple...Int16
OneHourRangeType
«XSDsimpleType»SubscribableType
PINType
unsignedInt
«XSDsimple...UInt32
SFDITypeunsignedLong
«XSDsimple...UInt40
DstRuleType
PENType
DERCurv eType
DERType
TimeTypelong
«XSDsimple...Int64
string
«XSDsimple...String42
LocaleType
hexBinary
«XSDsimple...HexBinary128 mRIDTypeApplianceLoadReductionType
PerCent
hexBinary
«XSDsimple...HexBinary16
RoleFlagsType
DERControlType
SignedPerCent
VersionType
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 163 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
AccumulationBehaviourType Object (UInt8) 5197 0 = Not Applicable (default, if not specified) 5198
3 = Cumulative 5199
The sum of the previous billing period values. Note: “Cumulative” is commonly used in 5200 conjunction with “demand.” Each demand reset causes the maximum demand value for the 5201 present billing period (since the last demand reset) to accumulate as an accumulative total of all 5202 maximum demands. So instead of “zeroing” the demand register, a demand reset has the affect of 5203 adding the present maximum demand to this accumulating total. 5204
4 = DeltaData 5205
The difference between the value at the end of the prescribed interval and the beginning of the 5206 interval. This is used for incremental interval data. 5207
Note: One common application would be for load profile data, another use might be to report the 5208 number of events within an interval (such as the number of equipment energizations within the 5209 specified period of time.) 5210
6 = Indicating 5211
As if a needle is swung out on the meter face to a value to indicate the current value. (Note: An 5212 “indicating” value is typically measured over hundreds of milliseconds or greater, or may imply a 5213 “pusher” mechanism to capture a value. Compare this to “instantaneous” which is measured over 5214 a shorter period of time.) 5215
9 = Summation 5216
A form of accumulation which is selective with respect to time. 5217
Note : “Summation” could be considered a specialization of “Bulk Quantity” according to the 5218 rules of inheritance where “Summation” selectively accumulates pulses over a timing pattern, and 5219 “BulkQuantity” accumulates pulses all of the time. 5220
12 = Instantaneous 5221
Typically measured over the fastest period of time allowed by the definition of the metric (usually 5222 milliseconds or tens of milliseconds.) (Note: “Instantaneous” was moved to attribute #3 in 61968-5223 9Ed2 from attribute #1 in 61968-9Ed1.) 5224
All other values reserved. 5225
ApplianceLoadReductionType Object (UInt8) 5226 0 - Delay Appliance Load 5227
Parameter requesting the appliance to respond by providing a moderate load reduction for the 5228 duration of a delay period. Typically referring to a “non-emergency” event in which appliances 5229 can continue operating if already in a load consuming period. 5230
1 - Temporary Appliance Load Reduction 5231
Parameter requesting the appliance to respond by providing an aggressive load reduction for a 5232 short time period. Typically referring to an “emergency/spinning reserve” event in which an 5233 appliance should start shedding load if currently in a load consuming period. 5234
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 164 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
* Full definition of how appliances react when receiving each parameter is document in the EPA 5235 document - ENERGY STAR® Program Requirements, Product Specification for Residential 5236 Refrigerators and Freezers, Eligibility Criteria 5, Draft 2 Version 5.0. 5237
All other values reserved. 5238
CommodityType Object (UInt8) 5239 0 = Not Applicable (default, if not specified) 5240
1 = Electricity secondary metered value (a premises meter is typically a secondary meter) 5241
2 = Electricity primary metered value 5242
4 = Air 5243
7 = NaturalGas 5244
8 = Propane 5245
9 = PotableWater 5246
10 = Steam 5247
11 = WasteWater 5248
12 = HeatingFluid 5249
13 = CoolingFluid 5250
All other values reserved. 5251
ConsumptionBlockType Object (UInt8) 5252 0 = Not Applicable (default, if not specified) 5253
1 = Block 1 5254
2 = Block 2 5255
3 = Block 3 5256
4 = Block 4 5257
5 = Block 5 5258
6 = Block 6 5259
7 = Block 7 5260
8 = Block 8 5261
9 = Block 9 5262
10 = Block 10 5263
11 = Block 11 5264
12 = Block 12 5265
13 = Block 13 5266
14 = Block 14 5267
15 = Block 15 5268
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 165 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
16 = Block 16 5269
All other values reserved. 5270
CurrencyCode Object (UInt16) 5271 Follows codes defined in [ISO 4217]. 5272
0 - Not Applicable (default, if not specified) 5273
36 - Australian Dollar 5274
124 - Canadian Dollar 5275
840 - US Dollar 5276
978 - Euro 5277
This is not a complete list. 5278
DataQualifierType Object (UInt8) 5279 0 = Not Applicable (default, if not specified) 5280
2 = Average 5281
8 = Maximum 5282
9 = Minimum 5283
12 = Normal 5284
All other values reserved. 5285
DateTimeInterval Object «Compound» () 5286 Interval of date and time. 5287
duration attribute (UInt32) 5288 Duration of the interval, in seconds. 5289
start attribute (TimeType) 5290 Date and time of the start of the interval. 5291
DeviceCategoryType Object (HexBinary32) 5292 The Device category types defined. 5293
Bit positions SHALL be defined as follows: 5294
0 - Programmable Communicating Thermostat 5295
1 - Strip Heaters 5296
2 - Baseboard Heaters 5297
3 - Water Heater 5298
4 - Pool Pump 5299
5 - Sauna 5300
6 - Hot tub 5301
7 - Smart Appliance 5302
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 166 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
8 - Irrigation Pump 5303
9 - Managed Commercial and Industrial (C&I) Loads 5304
10 - Simple misc. (Residential On/Off) loads 5305
11 - Exterior Lighting 5306
12 - Interior Lighting 5307
13 - Electric Vehicle 5308
14 - Generation Systems 5309
15 - Load Control Switch 5310
16 - Smart Inverter 5311
17 - EVSE 5312
18 - RESU 5313
19 - Energy Management System 5314
20 - Smart Energy Module 5315
All other values reserved. 5316
DstRuleType Object (HexBinary32) 5317 Bit map encoded rule from which is calculated the start or end time, within the current year, to 5318 which daylight savings time offset must be applied. 5319
The rule encoding: 5320
Bits 0 - 11: seconds 0 - 3599 5321
Bits 12 - 16: hours 0 - 23 5322
Bits 17 - 19: day of the week 0 = not applicable, 1 - 7 (Monday = 1) 5323
Bits:20 - 24: day of the month 0 = not applicable, 1 - 31 5324
Bits: 25 - 27: operator (detailed below) 5325
Bits: 28 - 31: month 1 - 12 5326
Rule value of 0xFFFFFFFF means rule processing/DST correction is disabled. 5327
The operators: 5328
0: DST starts/ends on the Day of the Month 5329
1: DST starts/ends on the Day of the Week that is on or after the Day of the Month 5330
2: DST starts/ends on the first occurrence of the Day of the Week in a month 5331
3: DST starts/ends on the second occurrence of the Day of the Week in a month 5332
4: DST starts/ends on the third occurrence of the Day of the Week in a month 5333
5: DST starts/ends on the forth occurrence of the Day of the Week in a month 5334
6: DST starts/ends on the fifth occurrence of the Day of the Week in a month 5335
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 167 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
7: DST starts/ends on the last occurrence of the Day of the Week in a month 5336
An example: DST starts on third Friday in March at 1:45 AM. The rule... 5337
Seconds: 2700 5338
Hours: 1 5339
Day of Week: 5 5340
Day of Month: 0 5341
Operator: 4 5342
Month: 3 5343
FlowDirectionType Object (UInt8) 5344 0 = Not Applicable (default, if not specified) 5345
1 = Forward (delivered to customer) 5346
19 = Reverse (received from customer) 5347
All other values reserved. 5348
KindType Object (UInt8) 5349 0 = Not Applicable (default, if not specified) 5350
3 = Currency 5351
8 = Demand 5352
12 = Energy 5353
37 = Power 5354
All other values reserved. 5355
LocaleType Object (String42) 5356 [RFC 4646] identifier of a language-region 5357
mRIDType Object (HexBinary128) 5358 A master resource identifier. The IANA PEN [PEN] provider ID SHALL be specified in bits 0-5359 31, the least-significant bits, and objects created by that provider SHALL be assigned unique IDs 5360 with the remaining 96 bits. 5361
0xFFFFFFFFFFFFFFFFFFFFFFFF[XXXXXXXX], where [XXXXXXXX] is the PEN, is 5362 reserved for a object that is being created (e.g., a ReadingSet for the current time that is still 5363 accumulating). 5364
Except for this special reserved identifier, each modification of an object (resource) 5365 representation MUST have a different "version". 5366
OneHourRangeType Object (Int16) 5367 A signed time offset, typically applied to a Time value, expressed in seconds, with range -3600 to 5368 3600. 5369
PENType Object (UInt32) 5370 IANA Private Enterprise Number [PEN]. 5371
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 168 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
PerCent Object (UInt16) 5372 Used for percentages, specified in hundredths of a percent, 0 - 10000. (10000 = 100%) 5373
PhaseCode Object (UInt8) 5374 0 = Not Applicable (default, if not specified) 5375
32 = Phase C (and S2) 5376
33 = Phase CN (and S2N) 5377
40 = Phase CA 5378
64 = Phase B 5379
65 = Phase BN 5380
66 = Phase BC 5381
128 = Phase A (and S1) 5382
129 = Phase AN (and S1N) 5383
132 = Phase AB 5384
224 = Phase ABC 5385
All other values reserved. 5386
PINType Object (UInt32) 5387 6 digit unsigned decimal integer (0 - 999999). 5388
(Note that this only requires 20 bits, if it can be allocated.) 5389
PowerOfTenMultiplierType Object (Int8) 5390 -9 = nano=x10^-9 5391
-6 = micro=x10^-6 5392
-3 = milli=x10^-3 5393
0 = none=x1 (default, if not specified) 5394
1 = deca=x10 5395
2 = hecto=x100 5396
3 = kilo=x1000 5397
6 = Mega=x10^6 5398
9 = Giga=x10^9 5399
This is not a complete list. Any integer between -9 and 9 SHALL be supported, indicating the 5400 power of ten multiplier for the units. 5401
PrimacyType Object (UInt8) 5402 Values possible for indication of "Primary" provider: 5403
0: In home energy management system 5404
1: Contracted premises service provider 5405
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 169 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
2: Non-contractual service provider 5406
All other values reserved. 5407
RealEnergy Object () 5408 Real electrical energy 5409
multiplier attribute (PowerOfTenMultiplierType) 5410 Multiplier for 'unit'. 5411
value attribute (UInt48) 5412 Value of the energy in Watt-hours. (uom 72) 5413
RoleFlagsType Object (HexBinary16) 5414 Specifies the roles that apply to a usage point. 5415
Bit 0 - isMirror - SHALL be set if the server is not the measurement device 5416
Bit 1 - isPremisesAggregationPoint - SHALL be set if the UsagePoint is the point of delivery for 5417 a premises 5418
Bit 2 - isPEV - SHALL be set if the usage applies to an electric vehicle 5419
Bit 3 - isDER - SHALL be set if the usage applies to a distributed energy resource, capable of 5420 delivering power to the grid. 5421
Bit 4 - isRevenueQuality - SHALL be set if usage was measured by a device certified as revenue 5422 quality 5423
Bit 5 - isDC - SHALL be set if the usage point measures direct current 5424
Bit 6 - isSubmeter - SHALL be set if the usage point is not a premises aggregation point 5425
Bit 7-15 - Reserved 5426
ServiceKind Object (UInt8) 5427 Service kind 5428
0 - electricity 5429
1 - gas 5430
2 - water 5431
3 - time 5432
4 - pressure 5433
5 - heat 5434
6 - cooling 5435
All other values reserved. 5436
SFDIType Object (UInt40) 5437 Unsigned integer, max inclusive 687194767359, which is 2^36-1 (68719476735), with added 5438 check digit. See Section 8.3.2 for check digit calculation. 5439
SignedPerCent Object (Int16) 5440 Used for signed percentages, specified in hundredths of a percent, -10000 - 10000. (10000 = 5441
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 170 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
100%) 5442
SignedRealEnergy Object () 5443 Real electrical energy, signed. 5444
multiplier attribute (PowerOfTenMultiplierType) 5445 Multiplier for 'unit'. 5446
value attribute (Int48) 5447 Value of the energy in Watt-hours. (uom 72) 5448
SubscribableType Object «XSDsimpleType» (UInt8) 5449 The subscribable values. 5450
0 - Resource does not support subscriptions 5451
1 - Resource supports non-conditional subscriptions 5452
2 - Resource supports conditional subscriptions 5453
3 - Resource supports both conditional and non-conditional subscriptions 5454
All other values reserved. 5455
TimeOffsetType Object (Int32) 5456 A signed time offset, typically applied to a Time value, expressed in seconds. 5457
TimeType Object (Int64) 5458 Time is a signed 64 bit value representing the number of seconds since 0 hours, 0 minutes, 0 5459 seconds, on the 1st of January, 1970, in UTC, not counting leap seconds. 5460
TOUType Object (UInt8) 5461 0 = Not Applicable (default, if not specified) 5462
1 = TOU A 5463
2 = TOU B 5464
3 = TOU C 5465
4 = TOU D 5466
5 = TOU E 5467
6 = TOU F 5468
7 = TOU G 5469
8 = TOU H 5470
9 = TOU I 5471
10 = TOU J 5472
11 = TOU K 5473
12 = TOU L 5474
13 = TOU M 5475
14 = TOU N 5476
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 171 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
15 = TOU O 5477
All other values reserved. 5478
UnitType Object (UInt8) 5479 The unit types defined for end device control target reductions. 5480
0 - kWh 5481
1 - kW 5482
2 - Watts 5483
3 - Cubic Meters 5484
4 - Cubic Feet 5485
5 - US Gallons 5486
6 - Imperial Gallons 5487
7 - BTUs 5488
8 - Liters 5489
9 - kPA (gauge) 5490
10 - kPA (absolute) 5491
11 - Mega Joule 5492
12 - Unitless 5493
All other values reserved. 5494
UnitValueType Object () 5495 Type for specification of a specific value, with units and power of ten multiplier. 5496
multiplier attribute (PowerOfTenMultiplierType) 5497 Multiplier for 'unit'. 5498
unit attribute (UomType) 5499 Unit in symbol 5500
value attribute (Int32) 5501 Value in units specified 5502
UomType Object (UInt8) 5503 0 = Not Applicable (default, if not specified) 5504
5 = A (Current in Amperes (RMS)) 5505
6 = Kelvin (Temperature) 5506
23 = Degrees Celsius (Relative temperature) 5507
29 = Voltage 5508
31 = J (Energy joule) 5509
33 = Hz (Frequency) 5510
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 172 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
38 =W (Real power in Watts) 5511
42 = m3 (Cubic Meter) 5512
61 = VA (Apparent power) 5513
63 = var (Reactive power) 5514
65 = CosTheta (Displacement Power Factor) 5515
67 = V² (Volts squared) 5516
69 = A² (Amp squared) 5517
71 = VAh (Apparent energy) 5518
72 = Wh (Real energy in Watt-hours) 5519
73 = varh (Reactive energy) 5520
106 = Ah (Ampere-hours / Available Charge) 5521
119 = ft3 (Cubic Feet) 5522
122 = ft3/h (Cubic Feet per Hour) 5523
125 = m3/h (Cubic Meter per Hour) 5524
128 = US gl (US Gallons) 5525
129 = US gl/h (US Gallons per Hour) 5526
130 = IMP gl (Imperial Gallons) 5527
131 = IMP gl/h (Imperial Gallons per Hour) 5528
132 = BTU 5529
133 = BTU/h 5530
134 = Liter 5531
137 = L/h (Liters per Hour) 5532
140 = PA(gauge) 5533
155 = PA(absolute) 5534
169 = Therm 5535
All other values reserved. 5536
VersionType Object (UInt16) 5537 Version SHALL indicate a distinct identifier for each revision of an IdentifiedObject. If not 5538 specified, a default version of "0" (initial version) SHALL be assumed. Upon modification of any 5539 IdentifiedObject, the mRID SHALL remain the same, but the version SHALL be incremented. 5540 Servers MAY NOT modify objects that they did not create, unless they were notified of the 5541 change from the entity controlling the object's PEN. 5542
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 173 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
15.1.2.4 Primitive Types Package 5543
Contains definitions of primitive data types based on XML schema primitives. 5544
5545
Figure 15-8: Primitive Types 5546
HexBinary8 Object «XSDsimpleType» (hexBinary) 5547 An 8-bit field encoded as a hex string (2 hex characters). Where applicable, bit 0, or the least 5548 significant bit, goes on the right. Note that hexBinary requires pairs of hex characters, so an odd 5549 number of characters requires a leading "0". 5550
HexBinary16 Object «XSDsimpleType» (hexBinary) 5551 A 16-bit field encoded as a hex string (4 hex characters max). Where applicable, bit 0, or the least 5552 significant bit, goes on the right. Note that hexBinary requires pairs of hex characters, so an odd 5553 number of characters requires a leading "0". 5554
HexBinary32 Object «XSDsimpleType» (hexBinary) 5555 A 32-bit field encoded as a hex string (8 hex characters max). Where applicable, bit 0, or the least 5556 significant bit, goes on the right. Note that hexBinary requires pairs of hex characters, so an odd 5557 number of characters requires a leading "0". 5558
HexBinary48 Object «XSDsimpleType» (hexBinary) 5559 A 48-bit field encoded as a hex string (12 hex characters max). Where applicable, bit 0, or the 5560 least significant bit, goes on the right. Note that hexBinary requires pairs of hex characters, so an 5561 odd number of characters requires a leading "0". 5562
HexBinary64 Object «XSDsimpleType» (hexBinary) 5563 A 64-bit field encoded as a hex string (16 hex characters max). Where applicable, bit 0, or the 5564 least significant bit, goes on the right. Note that hexBinary requires pairs of hex characters, so an 5565 odd number of characters requires a leading "0". 5566
HexBinary128 Object «XSDsimpleType» (hexBinary) 5567 A 128-bit field encoded as a hex string (32 hex characters max). Where applicable, bit 0, or the 5568 least significant bit, goes on the right. Note that hexBinary requires pairs of hex characters, so an 5569 odd number of characters requires a leading "0". 5570
class Primitiv e Types
unsignedShort
«XSDsimple...UInt16
unsignedInt
«XSDsimple...UInt32
unsignedLong
«XSDsimple...UInt48
unsignedLong
«XSDsimple...UInt64
unsignedByte
«XSDsimple...UInt8
string
«XSDsimple...String20
unsignedLong
«XSDsimple...UInt40
string
«XSDsimple...String32
string
«XSDsimple...String192
int
«XSDsimple...Int32
hexBinary
«XSDsimple...HexBinary64
hexBinary
«XSDsimple...HexBinary16
hexBinary
«XSDsimple...HexBinary32
string
«XSDsimple...String6
string
«XSDsimple...String42
byte
«XSDsimple...Int8
short
«XSDsimple...Int16
long
«XSDsimple...Int64
hexBinary
«XSDsimple...HexBinary8
hexBinary
«XSDsimple...HexBinary128
hexBinary
«XSDsimple...HexBinary160
long
«XSDsimple...Int48
string
«XSDsimple...String16
hexBinary
«XSDsimple...HexBinary48
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 174 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
HexBinary160 Object «XSDsimpleType» (hexBinary) 5571 A 160-bit field encoded as a hex string (40 hex characters max). Where applicable, bit 0, or the 5572 least significant bit, goes on the right. Note that hexBinary requires pairs of hex characters, so an 5573 odd number of characters requires a leading "0". 5574
String6 Object «XSDsimpleType» (string) 5575 Character string of max length 6. In order to limit internal storage, implementations SHALL 5576 reduce the length of strings using multi-byte characters so that the string may be stored using 5577 "maxLength" octets in the given encoding. 5578
String16 Object «XSDsimpleType» (string) 5579 Character string of max length 16. In order to limit internal storage, implementations SHALL 5580 reduce the length of strings using multi-byte characters so that the string may be stored using 5581 "maxLength" octets in the given encoding. 5582
String20 Object «XSDsimpleType» (string) 5583 Character string of max length 20. In order to limit internal storage, implementations SHALL 5584 reduce the length of strings using multi-byte characters so that the string may be stored using 5585 "maxLength" octets in the given encoding. 5586
String32 Object «XSDsimpleType» (string) 5587 Character string of max length 32. In order to limit internal storage, implementations SHALL 5588 reduce the length of strings using multi-byte characters so that the string may be stored using 5589 "maxLength" octets in the given encoding. 5590
String42 Object «XSDsimpleType» (string) 5591 Character string of max length 42. In order to limit internal storage, implementations SHALL 5592 reduce the length of strings using multi-byte characters so that the string may be stored using 5593 "maxLength" octets in the given encoding. 5594
String192 Object «XSDsimpleType» (string) 5595 Character string of max length 192. For all string types, in order to limit internal storage, 5596 implementations SHALL reduce the length of strings using multi-byte characters so that the 5597 string may be stored using "maxLength" octets in the given encoding. 5598
UInt8 Object «XSDsimpleType» (unsignedByte) 5599 Unsigned integer, max inclusive 255 (2^8-1) 5600
UInt16 Object «XSDsimpleType» (unsignedShort) 5601 Unsigned integer, max inclusive 65535 (2^16-1) 5602
UInt32 Object «XSDsimpleType» (unsignedInt) 5603 Unsigned integer, max inclusive 4294967295 (2^32-1) 5604
UInt40 Object «XSDsimpleType» (unsignedLong) 5605 Unsigned integer, max inclusive 1099511627775 (2^40-1) 5606
UInt48 Object «XSDsimpleType» (unsignedLong) 5607 Unsigned integer, max inclusive 281474976710655 (2^48-1) 5608
UInt64 Object «XSDsimpleType» (unsignedLong) 5609 Unsigned integer, max inclusive 18446744073709551615 (2^64-1) 5610
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 175 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Int8 Object «XSDsimpleType» (byte) 5611 Signed integer, min -128 max +127 5612
Int16 Object «XSDsimpleType» (short) 5613 Signed integer, min -32768 max +32767 5614
Int32 Object «XSDsimpleType» (int) 5615 Signed integer, max inclusive 2147483647 (2^31), min inclusive -2147483647 (same as xs:int) 5616
Int48 Object «XSDsimpleType» (long) 5617 Signed integer, max inclusive 140737488355328 (2^47), min inclusive -140737488355328 5618
Int64 Object «XSDsimpleType» (long) 5619 Signed integer, max inclusive 9223372036854775807 (2^63), min inclusive -5620 9223372036854775808 (same as xs:long) 5621
15.1.3 EndDevice Package 5622
5623
5624
Figure 15-9: SelfDevice 5625
class SelfDev ice
EndDev ice
SubscribableListEndDev iceList
ListLinkEndDev iceListLink
FunctionSetAssignmentsBaseDev iceCapability
LinkDev iceInformationLink
LinkDev iceStatusLink
ListLinkFunctionSetAssignmentsListLink
ListLinkIPInterfaceListLink
LinkRegistrationLink
ListLinkSubscriptionListLink
SelfDev ice
LinkConfigurationLink
ListLinkLogEv entListLink
LinkPowerStatusLink
LinkSelfDev iceLink
SubscribableResourceAbstractDev ice
+ loadShedDeviceCategory :DeviceCategoryType [0..1]+ sFDI :SFDIType
LinkLoadShedAv ailabilityLink
LinkFileStatusLink
ListLinkFlowReserv ationRequestListLink
ListLinkFlowReserv ationResponseListLink
ListLinkDERListLink
0..1
0..10..10..10..10..10..10..10..1
0..1
0..*
0..10..10..10..10..1
0..1
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 176 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
5626
Figure 15-10: EndDevice 5627
AbstractDevice Object (SubscribableResource) 5628 The EndDevice providing the resources available within the DeviceCapabilities. 5629
loadShedDeviceCategory attribute (DeviceCategoryType) [0..1] 5630 This field is for use in devices that can shed load. If you are a device that does not respond to 5631 EndDeviceControls (for instance, an ESI), this field should not have any bits set. 5632
sFDI attribute (SFDIType) 5633 Short form of device identifier, WITH the checksum digit. See the Security section for additional details. 5634
DeviceStatus Object (Resource) 5635 Status of device 5636
changedTime attribute (TimeType) 5637 The time at which the reported values were recorded. 5638
onCount attribute (UInt16) [0..1] 5639 The number of times that the device has been turned on: Count of "device on" times, since the last time 5640 the counter was reset 5641
opState attribute (UInt8) [0..1] 5642 Device operational state: 5643
0 - Not applicable / Unknown 5644
class EndDev ice
ResourceRegistration
+ dateTimeRegistered :TimeType+ pIN :PINType
EndDev ice
ResourceFunctionSetAssignmentsBase
SubscriptionBaseSubscription
+ encoding :UInt8+ level :String16+ limit :UInt16+ notificationURI :anyURI
ResourceDev iceStatus
+ changedTime :TimeType+ onCount :UInt16 [0..1]+ opState :UInt8 [0..1] = 0+ opTime :UInt32 [0..1]
Temperature
+ multiplier :PowerOfTenMultiplierType+ subject :UInt8+ value :Int16
LinkRegistrationLink
ListLinkFunctionSetAssignmentsListLink
ListLinkSubscriptionListLink
LinkDev iceStatusLink
subjectThe subject of the temperature measurement0 - Enclosure1 - Transformer2 - HeatSink
LinkTimeLink
SubscribableResourceAbstractDev ice
+ loadShedDeviceCategory :DeviceCategoryType [0..1]+ sFDI :SFDIType
SubscribableListFunctionSetAssignmentsList
FunctionSetAssignments
+ description :String32 [0..1]+ mRID :mRIDType+ version :VersionType [0..1] = 0
«XSDattribute»+ subscribable :SubscribableType [0..1] = 0
ListSubscriptionList
0..10..10..1
0..10..*
0..1
0..1
0..* 0..*
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 177 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
1 - Not operating 5645
2 - Operating 5646
3 - Starting up 5647
4 - Shutting down 5648
5 - At disconnect level 5649
6 - kW ramping 5650
7 - kVar ramping 5651
opTime attribute (UInt32) [0..1] 5652 Total time device has operated: re-settable: Accumulated time in seconds since the last time the counter 5653 was reset. 5654
EndDevice Object (AbstractDevice) 5655 Asset container that performs one or more end device functions. Contains information about 5656 individual devices in the network. 5657
EndDeviceList Object (SubscribableList) 5658 A List element to hold EndDevice objects. 5659
Registration Object (Resource) 5660 Registration represents an authorization to access the resources on a host. 5661
dateTimeRegistered attribute (TimeType) 5662 Contains the time at which this registration was created, by which clients MAY prioritize information 5663 providers with the most recent registrations, when no additional direction from the consumer is available. 5664
pIN attribute (PINType) 5665 Contains the registration PIN number associated with the device, including the checksum digit. 5666
SelfDevice Object (AbstractDevice) 5667 The EndDevice providing the resources available within the DeviceCapabilities. 5668
Temperature Object () 5669 Specification of a temperature. 5670
multiplier attribute (PowerOfTenMultiplierType) 5671 Multiplier for 'unit'. 5672
subject attribute (UInt8) 5673 The subject of the temperature measurement 5674
0 - Enclosure 5675
1 - Transformer 5676
2 - HeatSink 5677
value attribute (Int16) 5678 Value in Degrees Celsius (uom 23). 5679
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 178 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
15.1.4 FunctionSetAssignments Package 5680
5681
5682
Figure 15-11: FunctionSetAssignments 5683
FunctionSetAssignmentsBase Object (Resource) 5684 Defines a collection of function set instances that are to be used by one or more devices as 5685 indicated by the EndDevice object(s) of the server. 5686
FunctionSetAssignments Object (FunctionSetAssignmentsBase) 5687 Provides an identifiable, subscribable collection of resources for a particular device to consume. 5688
description attribute (String32) [0..1] 5689 The description is a human readable text describing or naming the object. 5690
mRID attribute (mRIDType) 5691 The global identifier of the object. 5692
subscribable attribute (SubscribableType) [0..1] «XSDattribute» 5693 Indicates whether or not subscriptions are supported for this resource, and whether or not conditional 5694 (thresholds) are supported. If not specified, is "not subscribable" (0). 5695
version attribute (VersionType) [0..1] 5696 Contains the version number of the object. See the type definition for details. 5697
FunctionSetAssignmentsList Object (SubscribableList) 5698 A List element to hold FunctionSetAssignments objects. 5699
class FunctionSetAssignments
ResourceFunctionSetAssignmentsBase
ListLinkDemandResponseProgramListLink
ListLinkDERProgramListLink
ListLinkMessagingProgramListLink
LinkTimeLink
ListLinkUsagePointListLink
ListLinkPrepaymentListLink
SubscribableListFunctionSetAssignmentsList
ListLinkTariffProfileListLink
ListLinkCustomerAccountListLink
ListLinkFunctionSetAssignmentsListLink
FunctionSetAssignments
+ description :String32 [0..1]+ mRID :mRIDType+ version :VersionType [0..1] = 0
«XSDattribute»+ subscribable :SubscribableType [0..1] = 0
ListLinkResponseSetListLink
ListLinkFileListLink
AbstractDeviceEndDev ice
0..10..1 0..10..10..10..10..10..10..10..1
0..1
0..*
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 179 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
15.1.5 Pub-Sub Package 5700
Contains resource definitions used to allow subscriptions and notifications of publications. 5701
5702
Figure 15-12: Pub-Sub 5703
Condition Object () 5704 Indicates a condition that must be satisfied for the Notification to be triggered. 5705
attributeIdentifier attribute (UInt8) 5706 0 = Reading value 5707
1-255 = Reserved 5708
lowerThreshold attribute (Int48) 5709 The value of the lower threshold 5710
upperThreshold attribute (Int48) 5711 The value of the upper threshold 5712
SubscriptionBase Object (Resource) 5713 Holds the information related to a client subscription to receive updates to a resource 5714 automatically. The actual resources may be passed in the Notification by specifying a specific 5715 xsi:type for the Resource and passing the full representation. 5716
subscribedResource attribute (anyURI) 5717 The resource for which the subscription applies. Query string parameters SHALL NOT be specified when 5718 subscribing to list resources. Should a query string parameter be specified, servers SHALL ignore them. 5719
Subscription Object (SubscriptionBase) 5720 Holds the information related to a client subscription to receive updates to a resource 5721
class Pub-Sub
Subscription
+ encoding :UInt8+ level :String16+ limit :UInt16+ notificationURI :anyURI
Notification
+ newResourceURI :anyURI [0..1]+ status :UInt8+ subscriptionURI :anyURI
Resource
Condition
+ attributeIdentifier :UInt8+ lowerThreshold :Int48+ upperThreshold :Int48
ListNotificationList
ListSubscriptionList
ListLinkNotificationListLink
ListLinkSubscriptionListLink
AbstractDeviceEndDev ice
attributeIdentifier0 = Reading value1-255 = Reserved
SubscriptionBase
+ subscribedResource :anyURI
«XSDattribute»::Resource+ href :anyURI [0..1]
status0 = Default Status1 = Subscription canceled, no additional information2 = Subscription canceled, resource moved3 = Subscription canceled, resource definition changed (e.g., SEP 2.0 to 2.1)4 = Subscription canceled, resource deletedAll other values reserved.
0..1
0..1
0..*
0..*
0..1
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 180 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
automatically. 5722
encoding attribute (UInt8) 5723 0 - application/sep+xml 5724
1 - application/sep-exi 5725
2-255 - reserved 5726
level attribute (String16) 5727 Contains the preferred schema and extensibility level indication such as "+S0" 5728
limit attribute (UInt16) 5729 This element is used to indicate the maximum number of list items that should be included in a 5730 notification when the subscribed resource changes. This limit is meant to be functionally equivalent to the 5731 ‘limit’ query string parameter, but applies to both list resources as well as other resources. For list 5732 resources, if a limit of ‘0’ is specified, then notifications SHALL contain a list resource with results=’0’ 5733 (equivalent to a simple change notification). For list resources, if a limit greater than ‘0’ is specified, then 5734 notifications SHALL contain a list resource with results equal to the limit specified (or less, should the 5735 list contain fewer items than the limit specified or should the server be unable to provide the requested 5736 number of items for any reason) and follow the same rules for list resources (e.g., ordering). For non-list 5737 resources, if a limit of ‘0’ is specified, then notifications SHALL NOT contain a resource representation 5738 (equivalent to a simple change notification). For non-list resources, if a limit greater than ‘0’ is specified, 5739 then notifications SHALL contain the representation of the changed resource. 5740
notificationURI attribute (anyURI) 5741 The resource to which to post the notifications about the requested subscribed resource. Because this URI 5742 will exist on a server other than the one being POSTed to, this attribute SHALL be a fully-qualified 5743 absolute URI, not a relative reference. 5744
SubscriptionList Object (List) 5745 A List element to hold Subscription objects. 5746
Notification Object (SubscriptionBase) 5747 Holds the information related to a client subscription to receive updates to a resource 5748 automatically. The actual resources may be passed in the Notification by specifying a specific 5749 xsi:type for the Resource and passing the full representation. 5750
newResourceURI attribute (anyURI) [0..1] 5751 The new location of the resource, if moved. 5752
status attribute (UInt8) 5753 0 = Default Status 5754
1 = Subscription canceled, no additional information 5755
2 = Subscription canceled, resource moved 5756
3 = Subscription canceled, resource definition changed (e.g., SEP 2.0 to 2.1) 5757
4 = Subscription canceled, resource deleted 5758
All other values reserved. 5759
subscriptionURI attribute (anyURI) 5760 The subscription from which this notification was triggered. 5761
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 181 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
NotificationList Object (List) 5762 A List element to hold Notification objects. 5763
15.1.6 Response Package 5764
Contains definitions of objects enabling responses to be sent back to suppliers and providers. 5765
5766
Figure 15-13: Response 5767
AppliedTargetReduction Object () 5768 Specifies the value of the TargetReduction applied by the device. 5769
type attribute (UnitType) 5770 Enumerated field representing the type of reduction requested. 5771
value attribute (UInt16) 5772 Indicates the requested amount of the relevant commodity to be reduced. 5773
DrResponse Object (Response) 5774 A response to a Demand Response Load Control (EndDeviceControl) message. 5775
overrideDuration attribute (UInt16) [0..1] 5776 Indicates the amount of time, in seconds, that the client partially opts-out during the demand response 5777 event. When overriding within the allowed override duration, the client SHALL send a partial opt-out 5778 (Response status code 8) for partial opt-out upon completion, with the total time the event was overridden 5779 (this attribute) populated. The client SHALL send a no participation status response (status type 10) if the 5780 user partially opts-out for longer than EndDeviceControl.overrideDuration. 5781
PriceResponse Object (Response) 5782 A response related to a price message. 5783
class Response
SetPoint
+ coolingSetpoint :Int16 [0..1]+ heatingSetpoint :Int16 [0..1]
Offset
+ coolingOffset :UInt8 [0..1]+ heatingOffset :UInt8 [0..1]+ loadAdjustmentPercentageOffset :UInt8 [0..1]
DutyCycle
+ normalValue :UInt8
PriceResponse
TextResponse
DrResponse
+ overrideDuration :UInt16 [0..1]
ListResponseList
ResourceResponse
+ createdDateTime :TimeType [0..1]+ endDeviceLFDI :HexBinary160+ status :UInt8 [0..1]+ subject :mRIDType
AppliedTargetReduction
+ type :UnitType+ value :UInt16
ListLinkResponseSetListLink
IdentifiedObjectResponseSet
ListResponseSetList
ListLinkResponseListLink
ResourceFunctionSetAssignmentsBase
ApplianceLoadReduction
+ type :ApplianceLoadReductionType0..10..10..10..10..1
0..*
0..1
0..*
0..1
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 182 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Response Object (Resource) 5784 The Response object is the generic response data repository for functions which do not have 5785 additional specific data (e.g. DRLC has additional data fields (SetPoint) where Price and Text 5786 event do not). 5787
createdDateTime attribute (TimeType) [0..1] 5788 The createdDateTime field contains the date and time when the acknowledgement/status occurred in the 5789 client. The client will provide the timestamp to ensure the proper time is captured in case the response is 5790 delayed in reaching the server (server receipt time would not be the same as the actual confirmation time). 5791 The time reported from the client should be relative to the time server indicated by the 5792 FunctionSetAssignment that also indicated the event resource; if no FunctionSetAssignment exists, the 5793 time of the server where the event resource was hosted. 5794
endDeviceLFDI attribute (HexBinary160) 5795 Contains the LFDI of the device providing the response. 5796
status attribute (UInt8) [0..1] 5797 The status field contains the acknowledgement or status. Each event type (DR/LC, Price, or Text) can 5798 return different status information (e.g. an Acknowledge will be returned for a Price event where a DRLC 5799 event can return Event Received, Event Started, and Event Completed). The Status field value definitions 5800 are defined in Table 10-10 Response Types by Function Set. 5801
subject attribute (mRIDType) 5802 The subject field provides a method to match the response with the originating event. It is populated with 5803 the mRID of the original object. 5804
ResponseList Object (List) 5805 A List element to hold Response objects. 5806
ResponseSet Object (IdentifiedObject) 5807 A container for a ResponseList. 5808
ResponseSetList Object (List) 5809 A List element to hold ResponseSet objects. 5810
TextResponse Object (Response) 5811 A response to a text message 5812
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 183 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
15.1.7 Time Package 5813
5814
5815
Figure 15-14: Time 5816
Time Object (Resource) 5817 Contains the representation of time, constantly updated. 5818
currentTime attribute (TimeType) 5819 The current time, in the format defined by TimeType. 5820
dstEndTime attribute (TimeType) 5821 Time at which daylight savings ends (dstOffset no longer applied). Result of dstEndRule calculation. 5822
dstOffset attribute (TimeOffsetType) 5823 Daylight savings time offset from local standard time. A typical practice is advancing clocks one hour 5824 when daylight savings time is in effect, which would result in a positive dstOffset. 5825
dstStartTime attribute (TimeType) 5826 Time at which daylight savings begins (apply dstOffset). Result of dstStartRule calculation. 5827
localTime attribute (TimeType) [0..1] 5828 Local time: localTime = currentTime + tzOffset (+ dstOffset when in effect). 5829
quality attribute (UInt8) 5830 Metric indicating the quality of the time source from which the service acquired time. Lower (smaller) 5831 quality enumeration values are assumed to be more accurate. 5832
3 - time obtained from external authoritative source such as NTP 5833
4 - time obtained from level 3 source 5834
5 - time manually set or obtained from level 4 source 5835
6 - time obtained from level 5 source 5836
7 - time intentionally uncoordinated 5837
All other values are reserved for future use. 5838
class Time
ResourceTime
+ currentTime :TimeType+ dstEndTime :TimeType+ dstOffset :TimeOffsetType+ dstStartTime :TimeType+ localTime :TimeType [0..1]+ quality :UInt8+ tzOffset :TimeOffsetType
qualityMetric indicating the quality of the time source from which the service acquired time. Lower (smaller) quality enumeration values are assumed to be more accurate.3 - time obtained from external authoritative source such as NTP4 - time obtained from level 3 source5 - time manually set or obtained from level 4 source6 - time obtained from level 5 source7 - time intentionally uncoordinatedAll other values are reserved for future use.
LinkTimeLink
ResourceFunctionSetAssignmentsBase
ResourceDev iceStatus
Int64TimeType
notesTime is a signed 64 bit value representing the number of seconds since 0 hours, 0 minutes, 0 seconds, on the 1st of January, 1970, in UTC, not counting leap seconds.
0..1 0..1
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 184 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
tzOffset attribute (TimeOffsetType) 5839 Local time zone offset from currentTime. Does not include any daylight savings time offsets. For 5840 American time zones, a negative tzOffset SHALL be used (eg, EST = GMT-5 which is -18000). 5841
15.1.8 DeviceInformation Package 5842
Contains general information about devices. 5843
5844
Figure 15-15: DeviceInformation 5845
DeviceInformation Object (Resource) 5846 Contains identification and other information about the device that changes very infrequently, 5847 typically only when updates are applied, if ever. 5848
functionsImplemented attribute (HexBinary64) [0..1] 5849 Bitmap indicating the function sets used by the device as a client. 5850
0 - Device Capability 5851
1 - Self Device Resource 5852
2 - End Device Resource 5853
3 - Function Set Assignments 5854
4 - Subscription/Notification Mechanism 5855
5 - Response 5856
6 - Time 5857
class Dev iceInformation
ResourceDev iceInformation
+ functionsImplemented :HexBinary64 [0..1]+ lFDI :HexBinary160+ mfDate :TimeType+ mfHwVer :String32+ mfID :PENType+ mfInfo :String32 [0..1]+ mfModel :String32+ mfSerNum :String32+ primaryPower :PowerSourceType+ secondaryPower :PowerSourceType+ swActTime :TimeType+ swVer :String32
String42LocaleType
notes[RFC 4646] identifier of a language-region
UInt8PowerSourceType
notes0 - none1 - mains 2 - battery3 - local generation4 - emergency 5 - unknownAll other values reserved.
ResourceSupportedLocale
+ locale :LocaleType
LinkDev iceInformationLink
ListLinkSupportedLocaleListLink
ListSupportedLocaleList
SubscribableResourceAbstractDev ice
functionsImplementedBitmap indicating the function sets used by the device as a client.0 - Device Capability1 - Self Device Resource2 - End Device Resource3 - Function Set Assignments4 - Subscription/Notification Mechanism5 - Response6 - Time7 - Device Information8 - Power Status9 - Network Status10 - Log/Event Log11 - Configuration Resource12 - Software Download13 - DRLC14 - Metering15 - Pricing16 - Messaging17 - Bil l ing18 - Prepayment19 - Flow Reservation20 - DER Control
DRLCCapabilities
+ averageEnergy :RealEnergy+ maxDemand :ActivePower+ optionsImplemented :HexBinary32
optionsImplementedBitmap indicating the DRLC options implemented by the device.0 - Target reduction (kWh)1 - Target reduction (kW)2 - Target reduction (Watts)3 - Target reduction (Cubic Meters)4 - Target reduction (Cubic Feet)5 - Target reduction (US Gallons)6 - Target reduction (Imperial Gallons)7 - Target reduction (BTUs)8 - Target reduction (Liters)9 - Target reduction (kPA (gauge))10 - Target reduction (kPA (absolute))11 - Target reduction (Mega Joule)12 - Target reduction (Unitless)13-15 - Reserved16 - Temperature set point17 - Temperature offset18 - Duty cycle19 - Load adjustment percentage20 - Appliance load reduction21-32 - Reserved
RealEnergy
+ multiplier :PowerOfTenMultiplierType+ value :UInt48
0..1
0..1
0..*
0..1
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 185 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
7 - Device Information 5858
8 - Power Status 5859
9 - Network Status 5860
10 - Log/Event Log 5861
11 - Configuration Resource 5862
12 - Software Download 5863
13 - DRLC 5864
14 - Metering 5865
15 - Pricing 5866
16 - Messaging 5867
17 - Billing 5868
18 - Prepayment 5869
19 - Flow Reservation 5870
20 - DER Control 5871
lFDI attribute (HexBinary160) 5872 Long form device identifier. See the Security section for full details. 5873
mfDate attribute (TimeType) 5874 Date/time of manufacture 5875
mfHwVer attribute (String32) 5876 Manufacturer hardware version 5877
mfID attribute (PENType) 5878 The manufacturer's IANA Enterprise Number. 5879
mfInfo attribute (String32) [0..1] 5880 Manufacturer dependent information related to the manufacture of this device 5881
mfModel attribute (String32) 5882 Manufacturer's model number 5883
mfSerNum attribute (String32) 5884 Manufacturer assigned serial number 5885
primaryPower attribute (PowerSourceType) 5886 Primary source of power. 5887
secondaryPower attribute (PowerSourceType) 5888 Secondary source of power 5889
swActTime attribute (TimeType) 5890 Activation date/time of currently running software 5891
swVer attribute (String32) 5892 Currently running software version 5893
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 186 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
DRLCCapabilities Object () 5894 Contains information about the static capabilities of the device, to allow service providers to 5895 know what types of functions are supported, what the normal operating ranges and limits are, and 5896 other similar information, in order to provide better suggestions of applicable programs to receive 5897 the maximum benefit. 5898
averageEnergy attribute (RealEnergy) 5899 The average hourly energy usage when in normal operating mode. 5900
maxDemand attribute (ActivePower) 5901 The maximum demand rating of this end device. 5902
optionsImplemented attribute (HexBinary32) 5903 Bitmap indicating the DRLC options implemented by the device. 5904
0 - Target reduction (kWh) 5905
1 - Target reduction (kW) 5906
2 - Target reduction (Watts) 5907
3 - Target reduction (Cubic Meters) 5908
4 - Target reduction (Cubic Feet) 5909
5 - Target reduction (US Gallons) 5910
6 - Target reduction (Imperial Gallons) 5911
7 - Target reduction (BTUs) 5912
8 - Target reduction (Liters) 5913
9 - Target reduction (kPA (gauge)) 5914
10 - Target reduction (kPA (absolute)) 5915
11 - Target reduction (Mega Joule) 5916
12 - Target reduction (Unitless) 5917
13-15 - Reserved 5918
16 - Temperature set point 5919
17 - Temperature offset 5920
18 - Duty cycle 5921
19 - Load adjustment percentage 5922
20 - Appliance load reduction 5923
21-32 - Reserved 5924
SupportedLocale Object (Resource) 5925 Specifies a locale that is supported 5926
locale attribute (LocaleType) 5927 The code for a locale that is supported 5928
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 187 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
SupportedLocaleList Object (List) 5929 A List element to hold SupportedLocale objects. 5930
15.1.9 PowerStatus Package 5931
5932
5933
Figure 15-16: PowerStatus 5934
PowerStatus Object (Resource) 5935 Contains the status of the device's power sources 5936
batteryStatus attribute (UInt8) 5937 Battery system status 5938
0 = unknown 5939
1 = normal (more than LowChargeThreshold remaining) 5940
2 = low (less than LowChargeThreshold remaining) 5941
3 = depleted (0% charge remaining) 5942
4 = not applicable (mains powered only) 5943
changedTime attribute (TimeType) 5944 The time at which the reported values were recorded. 5945
currentPowerSource attribute (PowerSourceType) 5946 This value will be fixed for devices powered by a single source. This value may change for devices able 5947 to transition between multiple power sources (mains to battery backup, etc.). 5948
estimatedChargeRemaining attribute (PerCent) [0..1] 5949 Estimate of remaining battery charge as a percent of full charge. 5950
estimatedTimeRemaining attribute (UInt32) [0..1] 5951 Estimated time (in seconds) to total battery charge depletion (under current load) 5952
class PowerStatus
ResourcePowerStatus
+ batteryStatus :UInt8+ changedTime :TimeType+ currentPowerSource :PowerSourceType+ estimatedChargeRemaining :PerCent [0..1]+ estimatedTimeRemaining :UInt32 [0..1]+ sessionTimeOnBattery :UInt32 [0..1]+ totalTimeOnBattery :UInt32 [0..1]
UInt8PowerSourceType
notes0 - none1 - mains 2 - battery3 - local generation4 - emergency 5 - unknownAll other values reserved.
LinkPowerStatusLink
SubscribableResourceAbstractDev ice
PEVInfo
+ chargingPowerNow :ActivePower+ energyRequestNow :RealEnergy+ maxForwardPower :ActivePower+ minimumChargingDuration :UInt32+ targetStateOfCharge :PerCent+ timeChargeIsNeeded :TimeType+ timeChargingStatusPEV :TimeType
0..1
0..1
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 188 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
sessionTimeOnBattery attribute (UInt32) [0..1] 5953 If the device has a battery, this is the time since the device last switched to battery power, or the time 5954 since the device was restarted, whichever is less, in seconds. 5955
totalTimeOnBattery attribute (UInt32) [0..1] 5956 If the device has a battery, this is the total time the device has been on battery power, in seconds. It may 5957 be reset when the battery is replaced. 5958
PowerSourceType Object (UInt8) 5959 0 - none 5960
1 - mains 5961
2 - battery 5962
3 - local generation 5963
4 - emergency 5964
5 - unknown 5965
All other values reserved. 5966
PEVInfo Object () 5967 Contains attributes that can be exposed by PEVs and other devices that have charging 5968 requirements. 5969
chargingPowerNow attribute (ActivePower) 5970 This is the actual power flow in or out of the charger or inverter. This is calculated by the vehicle based 5971 on actual measurements. This number is positive for charging. 5972
energyRequestNow attribute (RealEnergy) 5973 This is the amount of energy that must be transferred from the grid to EVSE and PEV to achieve the 5974 target state of charge allowing for charger efficiency and any vehicle and EVSE parasitic loads. This is 5975 calculated by the vehicle and changes throughout the connection as forward or reverse power flow change 5976 the battery state of charge. This number is positive for charging. 5977
maxForwardPower attribute (ActivePower) 5978 This is maximum power transfer capability that could be used for charging the PEV to perform the 5979 requested energy transfer. It is the lower of the vehicle or EVSE physical power limitations. It is not 5980 based on economic considerations. The vehicle may draw less power than this value based on its charging 5981 cycle. The vehicle defines this parameter. This number is positive for charging power flow. 5982
minimumChargingDuration attribute (UInt32) 5983 This is computed by the PEV based on the charging profile to complete the energy transfer if the 5984 maximum power is authorized. The value will never be smaller than the ratio of the energy request to the 5985 power request because the charging profile may not allow the maximum power to be used throughout the 5986 transfer. This is a critical parameter for determining whether any slack time exists in the charging cycle 5987 between the current time and the TCIN. 5988
targetStateOfCharge attribute (PerCent) 5989 This is the target state of charge that is to be achieved during charging before the time of departure 5990 (TCIN). The default value is 100%. The value cannot be set to a value less than the actual state of charge. 5991
timeChargeIsNeeded attribute (TimeType) 5992
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 189 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Time Charge is Needed (TCIN) is the time that the PEV is expected to depart. The value is manually 5993 entered using controls and displays in the vehicle or on the EVSE or using a mobile device. It is 5994 authenticated and saved by the PEV. This value may be updated during a charging session. 5995
timeChargingStatusPEV attribute (TimeType) 5996 This is the time that the parameters are updated, except for changes to TCIN. 5997
15.1.10 NetworkStatus Package 5998
5999
6000
Figure 15-17: NetworkStatus 6001
IEEE_802_15_4 Object () 6002 Contains 802.15.4 link layer specific attributes. 6003
capabilityInfo attribute (HexBinary8) 6004 As defined by IEEE 802.15.4 6005
shortAddress attribute (UInt16) 6006
class NetworkStatus
ListRPLInstanceList
ResourceIPInterface
+ ifDescr :String192 [0..1]+ ifHighSpeed :UInt32 [0..1]+ ifInBroadcastPkts :UInt32 [0..1]+ ifIndex :UInt32 [0..1]+ ifInDiscards :UInt32 [0..1]+ ifInErrors :UInt32 [0..1]+ ifInMulticastPkts :UInt32 [0..1]+ ifInOctets :UInt32 [0..1]+ ifInUcastPkts :UInt32 [0..1]+ ifInUnknownProtos :UInt32 [0..1]+ ifMtu :UInt32 [0..1]+ ifName :String16 [0..1]+ ifOperStatus :UInt8 [0..1]+ ifOutBroadcastPkts :UInt32 [0..1]+ ifOutDiscards :UInt32 [0..1]+ ifOutErrors :UInt32 [0..1]+ ifOutMulticastPkts :UInt32 [0..1]+ ifOutOctets :UInt32 [0..1]+ ifOutUcastPkts :UInt32 [0..1]+ ifPromiscuousMode :boolean [0..1]+ ifSpeed :UInt32 [0..1]+ ifType :UInt16 [0..1]+ lastResetTime :Int64 [0..1]+ lastUpdatedTime :Int64 [0..1]
ListIPInterfaceList
ResourceRPLInstance
+ DODAGid :UInt8+ DODAGroot :boolean+ flags :UInt8+ groundedFlag :boolean+ MOP :UInt8+ PRF :UInt8+ rank :UInt16+ RPLInstanceID :UInt8+ versionNumber :UInt8
ResourceRPLSourceRoutes
+ DestAddress :HexBinary128+ SourceRoute :HexBinary128
ListRPLSourceRoutesList
ListLinkIPInterfaceListLink
ListLinkRPLInstanceListLink
ListLinkRPLSourceRoutesListLink
ResourceIPAddr
+ address :HexBinary128
ListIPAddrList
ListLinkIPAddrListLink
ListLinkLLInterfaceListLink
ListLLInterfaceList
ResourceLLInterface
+ CRCerrors :UInt32+ EUI64 :HexBinary64+ linkLayerType :UInt8+ LLAckNotRx :UInt32 [0..1]+ LLCSMAFail :UInt32 [0..1]+ LLFramesDropRx :UInt32 [0..1]+ LLFramesDropTx :UInt32 [0..1]+ LLFramesRx :UInt32 [0..1]+ LLFramesTx :UInt32 [0..1]+ LLMediaAccessFail :UInt32 [0..1]+ LLOctetsRx :UInt32 [0..1]+ LLOctetsTx :UInt32 [0..1]+ LLRetryCount :UInt32 [0..1]+ LLSecurityErrorRx :UInt32 [0..1]
SubscribableResourceAbstractDev ice
l inkLayerTypeSpecifies the type of l ink layer interface associated with the IPInterface. Values are below.0 = Unspecified 1 = IEEE 802.3 (Ethernet)2 = IEEE 802.11 (WLAN)3 = IEEE 802.15 (PAN)4 = IEEE 1901 (PLC)All other values reserved.
IEEE_802_15_4
+ capabilityInfo :HexBinary8+ shortAddress :UInt16
loWPAN
+ octetsRx :UInt32 [0..1]+ octetsTx :UInt32 [0..1]+ packetsRx :UInt32+ packetsTx :UInt32+ rxFragError :UInt32
ListNeighborList
ListLinkNeighborListLink
ResourceNeighbor
+ isChild :boolean+ linkQuality :UInt8+ shortAddress :UInt16
0..*
0..1
0..1
0..*
0..1
0..*
0..1
0..*
0..*
0..1
0..1
0..1
0..1
0..*
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 190 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
As defined by IEEE 802.15.4 6007
IPAddr Object (Resource) 6008 An Internet Protocol address object. 6009
address attribute (HexBinary128) 6010 An IP address value. 6011
IPAddrList Object (List) 6012 List of IPAddr instances. 6013
IPInterface Object (Resource) 6014 Specific IPInterface resource. This resource may be thought of as network status information for 6015 a specific network (IP) layer interface. 6016
ifDescr attribute (String192) [0..1] 6017 Use rules from [RFC 2863]. 6018
ifHighSpeed attribute (UInt32) [0..1] 6019 Use rules from [RFC 2863]. 6020
ifInBroadcastPkts attribute (UInt32) [0..1] 6021 Use rules from [RFC 2863]. 6022
ifIndex attribute (UInt32) [0..1] 6023 Use rules from [RFC 2863]. 6024
ifInDiscards attribute (UInt32) [0..1] 6025 Use rules from [RFC 2863]. Can be thought of as Input Datagrams Discarded. 6026
ifInErrors attribute (UInt32) [0..1] 6027 Use rules from [RFC 2863]. 6028
ifInMulticastPkts attribute (UInt32) [0..1] 6029 Use rules from [RFC 2863]. Can be thought of as Multicast Datagrams Received. 6030
ifInOctets attribute (UInt32) [0..1] 6031 Use rules from [RFC 2863]. Can be thought of as Bytes Received. 6032
ifInUcastPkts attribute (UInt32) [0..1] 6033 Use rules from [RFC 2863]. Can be thought of as Datagrams Received. 6034
ifInUnknownProtos attribute (UInt32) [0..1] 6035 Use rules from [RFC 2863]. Can be thought of as Datagrams with Unknown Protocol Received. 6036
ifMtu attribute (UInt32) [0..1] 6037 Use rules from [RFC 2863]. 6038
ifName attribute (String16) [0..1] 6039 Use rules from [RFC 2863]. 6040
ifOperStatus attribute (UInt8) [0..1] 6041 Use rules and assignments from [RFC 2863]. 6042
ifOutBroadcastPkts attribute (UInt32) [0..1] 6043 Use rules from [RFC 2863]. Can be thought of as Broadcast Datagrams Sent. 6044
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 191 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
ifOutDiscards attribute (UInt32) [0..1] 6045 Use rules from [RFC 2863]. Can be thought of as Output Datagrams Discarded. 6046
ifOutErrors attribute (UInt32) [0..1] 6047 Use rules from [RFC 2863]. 6048
ifOutMulticastPkts attribute (UInt32) [0..1] 6049 Use rules from [RFC 2863]. Can be thought of as Multicast Datagrams Sent. 6050
ifOutOctets attribute (UInt32) [0..1] 6051 Use rules from [RFC 2863]. Can be thought of as Bytes Sent. 6052
ifOutUcastPkts attribute (UInt32) [0..1] 6053 Use rules from [RFC 2863]. Can be thought of as Datagrams Sent. 6054
ifPromiscuousMode attribute (boolean) [0..1] 6055 Use rules from [RFC 2863]. 6056
ifSpeed attribute (UInt32) [0..1] 6057 Use rules from [RFC 2863]. 6058
ifType attribute (UInt16) [0..1] 6059 Use rules and assignments from [RFC 2863]. 6060
lastResetTime attribute (Int64) [0..1] 6061 Similar to ifLastChange in [RFC 2863]. 6062
lastUpdatedTime attribute (Int64) [0..1] 6063 The date/time of the reported status. 6064
IPInterfaceList Object (List) 6065 List of IPInterface instances. 6066
LLInterface Object (Resource) 6067 A link-layer interface object. 6068
CRCerrors attribute (UInt32) 6069 Contains the number of CRC errors since reset. 6070
EUI64 attribute (HexBinary64) 6071 Contains the EUI-64 of the link layer interface. 48 bit MAC addresses SHALL be changed into an EUI-64 6072 using the method defined in [RFC 4291], Appendix A. (The method is to insert "0xFFFE" as described in 6073 the reference.) 6074
linkLayerType attribute (UInt8) 6075 Specifies the type of link layer interface associated with the IPInterface. Values are below. 6076
0 = Unspecified 6077
1 = IEEE 802.3 (Ethernet) 6078
2 = IEEE 802.11 (WLAN) 6079
3 = IEEE 802.15 (PAN) 6080
4 = IEEE 1901 (PLC) 6081
All other values reserved. 6082
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 192 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
LLAckNotRx attribute (UInt32) [0..1] 6083 Number of times an ACK was not received for a frame transmitted (when ACK was requested). 6084
LLCSMAFail attribute (UInt32) [0..1] 6085 Number of times CSMA failed. 6086
LLFramesDropRx attribute (UInt32) [0..1] 6087 Number of dropped receive frames. 6088
LLFramesDropTx attribute (UInt32) [0..1] 6089 Number of dropped transmit frames. 6090
LLFramesRx attribute (UInt32) [0..1] 6091 Number of link layer frames received. 6092
LLFramesTx attribute (UInt32) [0..1] 6093 Number of link layer frames transmitted. 6094
LLMediaAccessFail attribute (UInt32) [0..1] 6095 Number of times access to media failed. 6096
LLOctetsRx attribute (UInt32) [0..1] 6097 Number of Bytes received. 6098
LLOctetsTx attribute (UInt32) [0..1] 6099 Number of Bytes transmitted. 6100
LLRetryCount attribute (UInt32) [0..1] 6101 Number of MAC transmit retries. 6102
LLSecurityErrorRx attribute (UInt32) [0..1] 6103 Number of receive security errors. 6104
LLInterfaceList Object (List) 6105 List of LLInterface instances. 6106
loWPAN Object () 6107 Contains information specific to 6LoWPAN. 6108
octetsRx attribute (UInt32) [0..1] 6109 Number of Bytes received 6110
octetsTx attribute (UInt32) [0..1] 6111 Number of Bytes transmitted 6112
packetsRx attribute (UInt32) 6113 Number of packets received 6114
packetsTx attribute (UInt32) 6115 Number of packets transmitted 6116
rxFragError attribute (UInt32) 6117 Number of errors receiving fragments 6118
Neighbor Object (Resource) 6119 Contains 802.15.4 link layer specific attributes. 6120
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 193 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
isChild attribute (boolean) 6121 True if the neighbor is a child. 6122
linkQuality attribute (UInt8) 6123 The quality of the link, as defined by 802.15.4 6124
shortAddress attribute (UInt16) 6125 As defined by IEEE 802.15.4 6126
NeighborList Object (List) 6127 List of 15.4 neighbors. 6128
RPLInstance Object (Resource) 6129 Specific RPLInstance resource. This resource may be thought of as network status information 6130 for a specific RPL instance associated with IPInterface. 6131
DODAGid attribute (UInt8) 6132 See [RFC 6550]. 6133
DODAGroot attribute (boolean) 6134 See [RFC 6550]. 6135
flags attribute (UInt8) 6136 See [RFC 6550]. 6137
groundedFlag attribute (boolean) 6138 See [RFC 6550]. 6139
MOP attribute (UInt8) 6140 See [RFC 6550]. 6141
PRF attribute (UInt8) 6142 See [RFC 6550]. 6143
rank attribute (UInt16) 6144 See [RFC 6550]. 6145
RPLInstanceID attribute (UInt8) 6146 See [RFC 6550]. 6147
versionNumber attribute (UInt8) 6148 See [RFC 6550]. 6149
RPLInstanceList Object (List) 6150 List of RPLInstances associated with the IPinterface. 6151
RPLSourceRoutes Object (Resource) 6152 A RPL source routes object. 6153
DestAddress attribute (HexBinary128) 6154 See [RFC 6554]. 6155
SourceRoute attribute (HexBinary128) 6156 See [RFC 6554]. 6157
RPLSourceRoutesList Object (List) 6158 List or RPL source routes if the hosting device is the DODAGroot 6159
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 194 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
15.1.11 LogEvents Package 6160
6161
6162
Figure 15-18: LogEvents 6163
LogEvent Object (Resource) 6164 A time stamped instance of a significant event detected by the device. 6165
createdDateTime attribute (TimeType) 6166 The date and time that the event occurred. 6167
extendedData attribute (UInt32) [0..1] 6168 May be used to transmit additional details about the event. 6169
functionSet attribute (UInt8) 6170 If the profileID indicates this is the Smart Energy Profile, the functionSet is defined by the Zigbee 6171 Alliance and SHALL be one of the values from the table below (Smart Energy Profile 2.0 function set 6172 identifiers). If the profileID is anything else, the functionSet is defined by the identified profile. 6173
0 General (not specific to a function set) 6174
1 Publish and Subscribe 6175
class LogEv ents
ResourceLogEv ent
+ createdDateTime :TimeType+ extendedData :UInt32 [0..1]+ functionSet :UInt8+ logEventCode :UInt8+ logEventID :UInt16+ logEventPEN :PENType+ profileID :UInt8
ListLinkLogEv entListLink
SubscribableListLogEv entList
SubscribableResourceAbstractDev ice
0..*
0..1
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 195 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
2 End Device 6176
3 Function Set Assignment 6177
4 Response 6178
5 Demand Response and Load Control 6179
6 Metering 6180
7 Pricing 6181
8 Messaging 6182
9 Billing 6183
10 Prepayment 6184
11 Distributed Energy Resources 6185
12 Time 6186
13 Software Download 6187
14 Device Information 6188
15 Power Status 6189
16 Network Status 6190
17 Log Event List 6191
18 Configuration 6192
19 Security 6193
All other values are reserved. 6194
logEventCode attribute (UInt8) 6195 An 8 bit unsigned integer. logEventCodes are scoped to a profile and a function set. If the profile is 6196 Smart Energy, the logEventCode is defined by the Zigbee Alliance within one of the function sets of 6197 Smart Energy Profile 2.0. If the profile is anything else, the logEventCode is defined by the specified 6198 profile. 6199
logEventID attribute (UInt16) 6200 This 16-bit value, combined with createdDateTime, profileID, and logEventPEN, should provide a 6201 reasonable level of uniqueness. 6202
logEventPEN attribute (PENType) 6203 The Private Enterprise Number(PEN) of the entity that defined the profileID, functionSet, and 6204 logEventCode of the logEvent. ZigBee-assigned logEventCodes SHALL use the ZigBee Alliance PEN. 6205 Combinations of profileID, functionSet, and logEventCode SHALL have unique meaning within a 6206 logEventPEN and are defined by the owner of the PEN. 6207
profileID attribute (UInt8) 6208 The profileID identifies which profile (HA, BA, SE, etc) defines the following event information. 6209
0 Not profile specific. 6210
1 Vendor Defined 6211
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 196 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
2 Smart Energy 6212
3 Home Automation 6213
4 Building Automation 6214
All other values are reserved. 6215
LogEventList Object (SubscribableList) 6216 A List element to hold LogEvent objects. 6217
15.1.12 Configuration Package 6218
6219
6220
Figure 15-19: Configuration 6221
Configuration Object (SubscribableResource) 6222 This resource contains various settings to control the operation of the device 6223
currentLocale attribute (LocaleType) 6224 [RFC 4646] identifier of the language-region currently in use. 6225
userDeviceName attribute (String32) 6226 User assigned, convenience name used for network browsing displays, etc. Example "My Thermostat" 6227
PowerConfiguration Object () 6228 Contains configuration related to the device's power sources 6229
batteryInstallTime attribute (TimeType) [0..1] 6230 Time/Date at which battery was installed, 6231
lowChargeThreshold attribute (UInt32) [0..1] 6232
class Configuration
TimeConfiguration
+ dstEndRule :DstRuleType+ dstOffset :TimeOffsetType+ dstStartRule :DstRuleType+ tzOffset :TimeOffsetType
SubscribableResourceConfiguration
+ currentLocale :LocaleType+ userDeviceName :String32
LinkConfigurationLink
PowerConfiguration
+ batteryInstallTime :TimeType [0..1]+ lowChargeThreshold :UInt32 [0..1]
SubscribableResourceAbstractDev ice
ResourcePriceResponseCfg
+ consumeThreshold :Int32+ maxReductionThreshold :Int32
ListLinkPriceResponseCfgListLink
ListPriceResponseCfgList
LinkRateComponentLink
0..10..1
0..1
0..1
1
0..*
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 197 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
In context of the PowerStatus resource, this is the value of EstimatedTimeRemaining below which 6233 BatteryStatus "low" is indicated and the LE_LOW_BATTERY is raised. 6234
PriceResponseCfg Object (Resource) 6235 Configuration data that specifies how price responsive devices SHOULD respond to price 6236 changes while acting upon a given RateComponent. 6237
consumeThreshold attribute (Int32) 6238 Price responsive clients acting upon the associated RateComponent SHOULD consume the associated 6239 commodity while the price is less than this threshold. 6240
maxReductionThreshold attribute (Int32) 6241 Price responsive clients acting upon the associated RateComponent SHOULD reduce consumption to the 6242 maximum extent possible while the price is greater than this threshold. 6243
PriceResponseCfgList Object (List) 6244 A List element to hold PriceResponseCfg objects. 6245
TimeConfiguration Object () 6246 Contains attributes related to the configuration of the time service. 6247
dstEndRule attribute (DstRuleType) 6248 Rule to calculate end of daylight savings time in the current year. Result of dstEndRule must be greater 6249 than result of dstStartRule. 6250
dstOffset attribute (TimeOffsetType) 6251 Daylight savings time offset from local standard time. 6252
dstStartRule attribute (DstRuleType) 6253 Rule to calculate start of daylight savings time in the current year. Result of dstEndRule must be greater 6254 than result of dstStartRule. 6255
tzOffset attribute (TimeOffsetType) 6256 Local time zone offset from UTCTime. Does not include any daylight savings time offsets. 6257
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 198 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
15.1.13 SoftwareDownload Package 6258
6259
6260
Figure 15-20: Files 6261
File Object (Resource) 6262 This resource contains various meta-data describing a file's characteristics. The meta-data 6263 provides general file information and also is used to support filtered queries of file lists 6264
activateTime attribute (TimeType) [0..1] 6265 This element MUST be set to the date/time at which this file is activated. If the activation time is less than 6266 or equal to current time, the LD MUST immediately place the file into the activated state (in the case of a 6267 firmware file, the file is now the running image). If the activation time is greater than the current time, 6268 the LD MUST wait until the specified activation time is reached, then MUST place the file into the 6269 activated state. Omission of this element means that the LD MUST NOT take any action to activate the 6270 file until a subsequent GET to this File resource provides an activateTime. 6271
fileURI attribute (anyURI) 6272 This element MUST be set to the URI location of the file binary artifact. This is the BLOB (binary large 6273 object) that is actually loaded by the LD 6274
lFDI attribute (HexBinary160) [0..1] 6275 This element MUST be set to the LFDI of the device for which this file in targeted. 6276
mfHwVer attribute (String32) [0..1] 6277 This element MUST be set to the hardware version for which this file is targeted. 6278
mfID attribute (PENType) 6279 This element MUST be set to the manufacturer's Private Enterprise Number (assigned by IANA). 6280
class Files
ResourceFile
+ activateTime :TimeType [0..1]+ fi leURI :anyURI+ lFDI :HexBinary160 [0..1]+ mfHwVer :String32 [0..1]+ mfID :PENType+ mfModel :String32+ mfSerNum :String32 [0..1]+ mfVer :String16+ size :UInt32+ type :HexBinary16
ListLinkFileListLink
ResourceFileStatus
+ activateTime :TimeType [0..1]+ loadPercent :UInt8+ nextRequestAttempt :TimeType+ request503Count :UInt16+ requestFailCount :UInt16+ status :UInt8+ statusTime :TimeType
statusCurrent loading status of the fi le indicated by FileLink. This element MUST be set to one of the following values:0 - No load operation in progress1 - File load in progress (first request for fi le content has been issued by LD)2 - File load failed3 - File loaded successfully (full content of fi le has been received by the LD), signature verification in progress4 - File signature verification failed5 - File signature verified, waiting to activate fi le.6 - File activation failed7 - File activation in progress 8 - File activated successfully (this state may not be reached/persisted through an image activation)9-255 - Reserved for future use.
LinkFileStatusLink
ResourceFunctionSetAssignmentsBase
SubscribableResourceAbstractDev ice
ListFileList
typeA value indicating the type of the fi le. MUST be one of the following values:00 = Software Image01 = Security Credential02 = Configuration03 = Log04–7FFF = SEP2 reserved8000-FFFF = Manufacturer defined
LinkFileLink0..1
0..1 0..1
0..*
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 199 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
mfModel attribute (String32) 6281 This element MUST be set to the manufacturer model number for which this file is targeted. The syntax 6282 and semantics are left to the manufacturer. 6283
mfSerNum attribute (String32) [0..1] 6284 This element MUST be set to the manufacturer serial number for which this file is targeted. The syntax 6285 and semantics are left to the manufacturer. 6286
mfVer attribute (String16) 6287 This element MUST be set to the software version information for this file. The syntax and semantics are 6288 left to the manufacturer. 6289
size attribute (UInt32) 6290 This element MUST be set to the total size (in bytes) of the file referenced by fileURI. 6291
type attribute (HexBinary16) 6292 A value indicating the type of the file. MUST be one of the following values: 6293
00 = Software Image 6294
01 = Security Credential 6295
02 = Configuration 6296
03 = Log 6297
04–7FFF = SEP2 reserved 6298
8000-FFFF = Manufacturer defined 6299
FileList Object (List) 6300 A List element to hold File objects. 6301
FileStatus Object (Resource) 6302 This object provides status of device file load and activation operations. 6303
activateTime attribute (TimeType) [0..1] 6304 Date/time at which this File, referred to by FileLink, will be activated. Omission of or presence and value 6305 of this element MUST exactly match omission or presence and value of the activateTime element from 6306 the File resource. 6307
loadPercent attribute (UInt8) 6308 This element MUST be set to the percentage of the file, indicated by FileLink, that was loaded during the 6309 latest load attempt. This value MUST be reset to 0 each time a load attempt is started for the File 6310 indicated by FileLink. This value MUST be increased when an LD receives HTTP response containing 6311 file content. This value MUST be set to 100 when the full content of the file has been received by the LD 6312
nextRequestAttempt attribute (TimeType) 6313 This element MUST be set to the time at which the LD will issue its next GET request for file content 6314 from the File indicated by FileLink 6315
request503Count attribute (UInt16) 6316 This value MUST be reset to 0 when FileLink is first pointed at a new File. This value MUST be 6317 incremented each time an 6318
LD receives a 503 error from the FS. 6319
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 200 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
requestFailCount attribute (UInt16) 6320 This value MUST be reset to 0 when FileLink is first pointed at a new File. This value MUST be 6321 incremented each time a GET request for file content failed. 503 errors MUST be excluded from this 6322 counter. 6323
status attribute (UInt8) 6324 Current loading status of the file indicated by FileLink. This element MUST be set to one of the following 6325 values: 6326
0 - No load operation in progress 6327
1 - File load in progress (first request for file content has been issued by LD) 6328
2 - File load failed 6329
3 - File loaded successfully (full content of file has been received by the LD), signature verification in 6330 progress 6331
4 - File signature verification failed 6332
5 - File signature verified, waiting to activate file. 6333
6 - File activation failed 6334
7 - File activation in progress 6335
8 - File activated successfully (this state may not be reached/persisted through an image activation) 6336
9-255 - Reserved for future use. 6337
statusTime attribute (TimeType) 6338 This element MUST be set to the time at which file status transitioned to the value indicated in the status 6339 element. 6340
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 201 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
15.1.14 DRLC Package 6341
Contains definitions for Demand Response Load Control functionality. 6342
6343
Figure 15-21: DRLC Event 6344
DRLC Ev ent
DutyCycle
+ normalValue :UInt8
IdentifiedObjectDemandResponseProgram
+ availabil ityUpdatePercentChangeThreshold :PerCent [0..1] = 0+ availabil ityUpdatePowerChangeThreshold :ActivePower [0..1] = 0+ primacy :PrimacyType::IdentifiedObject+ description :String32 [0..1]+ mRID :mRIDType+ version :VersionType [0..1] = 0
«XSDattribute»::Resource+ href :anyURI [0..1]
SetPoint
+ coolingSetpoint :Int16 [0..1]+ heatingSetpoint :Int16 [0..1]
Offset
+ coolingOffset :UInt8 [0..1]+ heatingOffset :UInt8 [0..1]+ loadAdjustmentPercentageOffset :UInt8 [0..1]
ResourceFunctionSetAssignmentsBase
Ev entStatus
+ currentStatus :UInt8+ dateTime :TimeType+ potentiallySuperseded :boolean+ potentiallySupersededTime :TimeType [0..1]+ reason :String192 [0..1]
TargetReduction
+ type :UnitType+ value :UInt16
EndDev iceControl
+ deviceCategory :DeviceCategoryType+ drProgramMandatory :boolean+ loadShiftForward :boolean+ overrideDuration :UInt16 [0..1] = 0::RandomizableEvent+ randomizeDuration :OneHourRangeType [0..1] = 0+ randomizeStart :OneHourRangeType [0..1] = 0::Event+ creationTime :TimeType+ interval :DateTimeInterval::RespondableSubscribableIdentifiedObject+ description :String32 [0..1]+ mRID :mRIDType+ version :VersionType [0..1] = 0
«XSDattribute»::RespondableSubscribableIdentifiedObject+ subscribable :SubscribableType [0..1] = 0::RespondableResource+ replyTo :anyURI [0..1]+ responseRequired :HexBinary8 [0..1] = 00::Resource+ href :anyURI [0..1]
HexBinary32Dev iceCategoryType
notesThe Device category types defined.Bit positions SHALL be defined as follows:0 - Programmable Communicating Thermostat 1 - Strip Heaters 2 - Baseboard Heaters 3 - Water Heater 4 - Pool Pump 5 - Sauna 6 - Hot tub7 - Smart Appliance 8 - Irrigation Pump 9 - Managed Commercial and Industrial (C&I) Loads 10 - Simple misc. (Residential On/Off) loads 11 - Exterior Lighting 12 - Interior Lighting 13 - Electric Vehicle 14 - Generation Systems 15 - Load Control Switch 16 - Smart Inverter 17 - EVSE 18 - RESU 19 - Energy Management System 20 - Smart Energy ModuleAll other values reserved.
ListLinkDemandResponseProgramListLink
ListLinkEndDev iceControlListLink
ListLinkActiv eEndDev iceControlListLink
RandomizableEv ent
+ randomizeDuration :OneHourRangeType [0..1] = 0+ randomizeStart :OneHourRangeType [0..1] = 0
RespondableSubscribableIdentifiedObjectEv ent
+ creationTime :TimeType+ interval :DateTimeInterval
ApplianceLoadReduction
+ type :ApplianceLoadReductionType
0..1
0..1
0..1
0..10..10..10..10..1
1
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 202 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
6345
Figure 15-22: Load Shed Availability 6346
ApplianceLoadReduction Object () 6347 The ApplianceLoadReduction object is used by a Demand Response service provider to provide 6348 signals for ENERGY STAR compliant appliances. See the definition of 6349 ApplianceLoadReductionType for more information. 6350
type attribute (ApplianceLoadReductionType) 6351 Indicates the type of appliance load reduction requested. 6352
DemandResponseProgram Object (IdentifiedObject) 6353 Demand response program. 6354
availabilityUpdatePercentChangeThreshold attribute (PerCent) [0..1] 6355 This attribute allows program providers to specify the requested granularity of updates to 6356 LoadShedAvailability sheddablePercent. If not present, or set to 0, then updates to LoadShedAvailability 6357 SHALL NOT be posted. If present and greater than zero, then clients SHALL post their 6358 LoadShedAvailability if it has not previously been posted, and thereafter if the difference between the 6359 previously posted value and the current value of LoadShedAvailability sheddablePercent is greater than 6360 availabilityUpdatePercentChangeThreshold. 6361
availabilityUpdatePowerChangeThreshold attribute (ActivePower) [0..1] 6362 This attribute allows program providers to specify the requested granularity of updates to 6363 LoadShedAvailability sheddablePower. If not present, or set to 0, then updates to LoadShedAvailability 6364 SHALL NOT be posted. If present and greater than zero, then clients SHALL post their 6365 LoadShedAvailability if it has not previously been posted, and thereafter if the difference between the 6366 previously posted value and the current value of LoadShedAvailability sheddablePower is greater than 6367 availabilityUpdatePowerChangeThreshold. 6368
class Load Shed Av ailability
ResourceLoadShedAv ailability
+ availabilityDuration :UInt32 [0..1]+ sheddablePercent :PerCent [0..1]+ sheddablePower :ActivePower [0..1]
«XSDattribute»::Resource+ href :anyURI [0..1]
LinkDemandResponseProgramLink
SubscribableResourceAbstractDev ice
LinkLoadShedAv ailabilityLink
0..1
0..1
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 203 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
primacy attribute (PrimacyType) 6369 Indicates the relative primacy of the provider of this program. 6370
DemandResponseProgramList Object (SubscribableList) 6371 A List element to hold DemandResponseProgram objects. 6372
DutyCycle Object () 6373 Duty cycle control is a device specific issue and is managed by the device. The duty cycle of the 6374 device under control should span the shortest practical time period in accordance with the nature 6375 of the device under control and the intent of the request for demand reduction. The default 6376 factory setting SHOULD be three minutes for each 10% of duty cycle. This indicates that the 6377 default time period over which a duty cycle is applied is 30 minutes, meaning a 10% duty cycle 6378 would cause a device to be ON for 3 minutes. The “off state” SHALL precede the “on state”. 6379
normalValue attribute (UInt8) 6380 Contains the maximum On state duty cycle applied by the end device, as a percentage of time. The field 6381 not present indicates that this field has not been used by the end device. 6382
EndDeviceControl Object (RandomizableEvent) 6383 Instructs an EndDevice to perform a specified action. 6384
deviceCategory attribute (DeviceCategoryType) 6385 Specifies the bitmap indicating the categories of devices that SHOULD respond. Devices SHOULD 6386 ignore events that do not indicate their device category. 6387
drProgramMandatory attribute (boolean) 6388 A flag to indicate if the EndDeviceControl is considered a mandatory event as defined by the service 6389 provider issuing the EndDeviceControl. The drProgramMandatory flag alerts the client/user that they will 6390 be subject to penalty or ineligibility based on the service provider’s program rules for that 6391 EndDeviceCategory. 6392
loadShiftForward attribute (boolean) 6393 Indicates that the event intends to increase consumption. A value of true indicates the intention to increase 6394 usage value, and a value of false indicates the intention to decrease usage. 6395
overrideDuration attribute (UInt16) [0..1] 6396 The overrideDuration attribute provides a duration, in seconds, for which a client device is allowed to 6397 override this EndDeviceControl and still meet the contractual agreement with a service provider without 6398 opting out. If overrideDuration is not specified, then it SHALL default to 0. 6399
EndDeviceControlList Object (SubscribableList) 6400 A List element to hold EndDeviceControl objects. 6401
LoadShedAvailability Object (Resource) 6402 Indicates current consumption status and ability to shed load. 6403
availabilityDuration attribute (UInt32) [0..1] 6404 Indicates for how many seconds the consuming device will be able to reduce consumption at the 6405 maximum response level. 6406
sheddablePercent attribute (PerCent) [0..1] 6407 Maximum percent of current operating load that is estimated to be sheddable. 6408
sheddablePower attribute (ActivePower) [0..1] 6409
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 204 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Maximum amount of current operating load that is estimated to be sheddable, in Watts. 6410
Offset Object () 6411 If a temperature offset is sent that causes the heating or cooling temperature set point to exceed 6412 the limit boundaries that are programmed into the device, the device SHALL respond by setting 6413 the temperature at the limit. 6414
If an EDC is being targeted at multiple devices or to a device that controls multiple devices (e.g., 6415 EMS), it can provide multiple Offset types within one EDC. For events with multiple Offset 6416 types, a client SHALL select the Offset that best fits their operating function. 6417
Alternatively, an event with a single Offset type can be targeted at an EMS in order to request a 6418 percentage load reduction on the average energy usage of the entire premise. An EMS SHOULD 6419 use the Metering function set to determine the initial load in the premise, reduce energy 6420 consumption by controlling devices at its disposal, and at the conclusion of the event, once again 6421 use the Metering function set to determine if the desired load reduction was achieved. 6422
coolingOffset attribute (UInt8) [0..1] 6423 The value change requested for the cooling offset, in degree C / 10. The value should be added to the 6424 normal set point for cooling, or if loadShiftForward is true, then the value should be subtracted from the 6425 normal set point. 6426
heatingOffset attribute (UInt8) [0..1] 6427 The value change requested for the heating offset, in degree C / 10. The value should be subtracted for 6428 heating, or if loadShiftForward is true, then the value should be added to the normal set point. 6429
loadAdjustmentPercentageOffset attribute (UInt8) [0..1] 6430 The value change requested for the load adjustment percentage, in tenths of a percent . The value should 6431 be subtracted from the normal setting, or if loadShiftForward is true, then the value should be added to the 6432 normal setting. 6433
SetPoint Object () 6434 The SetPoint object is used to apply specific temperature set points to a temperature control 6435 device. The values of the heatingSetpoint and coolingSetpoint attributes SHALL be calculated as 6436 follows: 6437
Cooling/Heating Temperature Set Point / 100 = temperature in degrees Celsius where -273.15°C 6438 <= temperature <= 327.67°C, corresponding to a Cooling and/or Heating Temperature Set Point. 6439 The maximum resolution this format allows is 0.01°C. 6440
The field not present in a Response indicates that this field has not been used by the end device. 6441
If a temperature is sent that exceeds the temperature limit boundaries that are programmed into 6442 the device, the device SHALL respond by setting the temperature at the limit. 6443
coolingSetpoint attribute (Int16) [0..1] 6444 This attribute represents the cooling temperature set point in degrees Celsius / 100. (Hundredths of a 6445 degree C) 6446
heatingSetpoint attribute (Int16) [0..1] 6447 This attribute represents the heating temperature set point in degrees Celsius / 100. (Hundredths of a 6448 degree C) 6449
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 205 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
TargetReduction Object () 6450 The TargetReduction object is used by a Demand Response service provider to provide a 6451 RECOMMENDED threshold that a device/premises should maintain its consumption below. For 6452 example, a service provider can provide a RECOMMENDED threshold of some kWh for a 3-6453 hour event. This means that the device/premises would maintain its consumption below the 6454 specified limit for the specified period. 6455
type attribute (UnitType) 6456 Indicates the type of reduction requested. 6457
value attribute (UInt16) 6458 Indicates the requested amount of the relevant commodity to be reduced. 6459
15.1.15 Metering Package 6460
Contains definitions related to measurements of energy at usage points. 6461
6462
Figure 15-23: Metering Data 6463
Metering Data
ResourceReadingType
+ accumulationBehaviour :AccumulationBehaviourType [0..1] = 0+ calorificValue :UnitValueType [0..1]+ commodity :CommodityType [0..1] = 0+ conversionFactor :UnitValueType [0..1] = 1+ dataQualifier :DataQualifierType [0..1] = 0+ flowDirection :FlowDirectionType [0..1] = 0+ intervalLength :UInt32 [0..1]+ kind :KindType [0..1] = 0+ maxNumberOfIntervals :UInt8 [0..1]+ numberOfConsumptionBlocks :UInt8 [0..1] = 0+ numberOfTouTiers :UInt8 [0..1] = 0+ phase :PhaseCode [0..1] = 0+ powerOfTenMultiplier :PowerOfTenMultiplierType [0..1] = 0+ subIntervalLength :UInt32 [0..1]+ supplyLimit :UInt48 [0..1]+ tieredConsumptionBlocks :boolean [0..1] = false+ uom :UomType [0..1] = 0
MeterReadingBaseMeterReading
::IdentifiedObject+ description :String32 [0..1]+ mRID :mRIDType+ version :VersionType [0..1] = 0
«XSDattribute»::Resource+ href :anyURI [0..1]
UsagePoint
UInt8Serv iceKind
notesService kind0 - electricity1 - gas2 - water3 - time4 - pressure5 - heat6 - coolingAll other values reserved.
ListLinkMeterReadingListLink
LinkReadingTypeLink
ReadingSetBaseReadingSet
ListLinkReadingSetListLink
IdentifiedObjectUsagePointBase
+ roleFlags :RoleFlagsType+ serviceCategoryKind :ServiceKind+ status :UInt8
roleFlagsSpecifies the roles that apply to the usage point.
statusSpecifies the current status of theservice at this usage point.0 = off1 = on
LinkReadingLink
ReadingBaseReading
+ localID :HexBinary16 [0..1]::ReadingBase+ consumptionBlock :ConsumptionBlockType [0..1] = 0+ qualityFlags :HexBinary16 [0..1] = 00+ timePeriod :DateTimeInterval [0..1]+ touTier :TOUType [0..1] = 0+ value :Int48 [0..1]
«XSDattribute»+ subscribable :SubscribableType [0..1] = 0::Resource+ href :anyURI [0..1]
ListLinkReadingListLink
ListLinkRateComponentListLink
SubscribableListUsagePointList
qualityFlagsList of codes indicating the quality of the reading, using specification:
Bit 0 - valid: data that has gone through all required validation checks and either passed them all or has been verified Bit 1 - manually edited: Replaced or approved by a humanBit 2 - estimated using reference day: data value was replaced by a machine computed value based on analysis of historical data using the same type of measurement.Bit 3 - estimated using linear interpolation: data value was computed using linear interpolation based on the readings before and after itBit 4 - questionable: data that has failed one or more checksBit 5 - derived: data that has been calculated (using logic or mathematical operations), not necessarily measured directly Bit 6 - projected (forecast): data that has been calculated as a projection or forecast of future readings
HexBinary16RoleFlagsType
notesSpecifies the roles that apply to a usage point.Bit 0 - isMirror - SHALL be set if the server is not the measurement deviceBit 1 - isPremisesAggregationPoint - SHALL be set if the UsagePoint is the point of delivery for a premisesBit 2 - isPEV - SHALL be set if the usage applies to an electric vehicleBit 3 - isDER - SHALL be set if the usage applies to a distributed energy resource, capable of delivering power to the grid.Bit 4 - isRevenueQuality - SHALL be set if usage was measured by a device certified as revenue qualityBit 5 - isDC - SHALL be set if the usage point measures direct current Bit 6 - isSubmeter - SHALL be set if the usage point is not a premises aggregation pointBit 7-15 - Reserved
0..1
0..1
1
0..1
0..1
0..1
0..*
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 206 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
6464
Figure 15-24: Metering Data Types 6465
MeterReading Object (MeterReadingBase) 6466 Set of values obtained from the meter. 6467
MeterReadingList Object (SubscribableList) 6468 A List element to hold MeterReading objects. 6469
Reading Object (ReadingBase) 6470 Specific value measured by a meter or other asset. 6471
localID attribute (HexBinary16) [0..1] 6472 The local identifier for this reading within the reading set. localIDs are assigned in order of creation time. 6473 For interval data, this value SHALL increase with each interval time, and for block/tier readings, localID 6474 SHALL not be specified. 6475
subscribable attribute (SubscribableType) [0..1] «XSDattribute» 6476 Indicates whether or not subscriptions are supported for this resource, and whether or not conditional 6477 (thresholds) are supported. If not specified, is "not subscribable" (0). 6478
ReadingList Object (SubscribableList) 6479 A List element to hold Reading objects. 6480
ReadingSet Object (ReadingSetBase) 6481 A set of Readings of the ReadingType indicated by the parent MeterReading. 6482
ReadingSetList Object (SubscribableList) 6483 A List element to hold ReadingSet objects. 6484
ReadingType Object (Resource) 6485 Type of data conveyed by a specific Reading. See IEC 61968 Part 9 Annex C for full definitions 6486
Metering Data Types
Data types based on CIM 61968-9 Annex C, D 2010-12-06 version
UInt8FlowDirectionType
notes0 = Not Applicable (default, if not specified)1 = Forward (delivered to customer)19 = Reverse (received from customer)All other values reserved.
UInt8AccumulationBehav iourType
UInt8DataQualifierType
notes0 = Not Applicable (default, if not specified)2 = Average8 = Maximum9 = Minimum12 = NormalAll other values reserved.
UInt8CommodityType
notes0 = Not Applicable (default, if not specified)1 = Electricity secondary metered value (a premises meteris typically a secondary meter)2 = Electricity primary metered value4 = Air7 = NaturalGas8 = Propane9 = PotableWater10 = Steam11 = WasteWater12 = HeatingFluid13 = CoolingFluidAll other values reserved.
UInt8KindType
notes0 = Not Applicable (default, if not specified)3 = Currency8 = Demand12 = Energy37 = PowerAll other values reserved.
UInt8TOUType
notes0 = Not Applicable (default, if not specified)1 = TOU A2 = TOU B3 = TOU C4 = TOU D5 = TOU E6 = TOU F7 = TOU G8 = TOU H9 = TOU I10 = TOU J11 = TOU K12 = TOU L13 = TOU M14 = TOU N15 = TOU OAll other values reserved.
UInt8ConsumptionBlockType
notes0 = Not Applicable (default, if not specified)1 = Block 12 = Block 23 = Block 34 = Block 45 = Block 56 = Block 67 = Block 78 = Block 89 = Block 910 = Block 1011 = Block 1112 = Block 1213 = Block 1314 = Block 1415 = Block 1516 = Block 16All other values reserved.
Int8PowerOfTenMultiplierType
notes-9 = nano=x10^-9-6 = micro=x10^-6-3 = mill i=x10^-30 = none=x1 (default, if not specified)1 = deca=x102 = hecto=x1003 = kilo=x10006 = Mega=x10^69 = Giga=x10^9This is not a complete list. Any integer between -9 and 9 SHALL be supported, indicating the power of ten multiplier for the units.
UInt8UomType
notes0 = Not Applicable (default, if not specified)5 = A (Current in Amperes (RMS))6 = Kelvin (Temperature)23 = Degrees Celsius (Relative temperature)29 = Voltage31 = J (Energy joule)33 = Hz (Frequency)38 =W (Real power in Watts)42 = m3 (Cubic Meter)61 = VA (Apparent power)63 = var (Reactive power)65 = CosTheta (Displacement Power Factor)67 = V² (Volts squared)69 = A² (Amp squared)71 = VAh (Apparent energy)72 = Wh (Real energy in Watt-hours)73 = varh (Reactive energy)106 = Ah (Ampere-hours / Available Charge)119 = ft3 (Cubic Feet)122 = ft3/h (Cubic Feet per Hour)125 = m3/h (Cubic Meter per Hour)128 = US gl (US Gallons)129 = US gl/h (US Gallons per Hour)130 = IMP gl (Imperial Gallons)131 = IMP gl/h (Imperial Gallons per Hour)132 = BTU133 = BTU/h134 = Liter137 = L/h (Liters per Hour)140 = PA(gauge)155 = PA(absolute)169 = ThermAll other values reserved.
UInt8PhaseCode
notes0 = Not Applicable (default,if not specified)32 = Phase C (and S2)33 = Phase CN (and S2N)40 = Phase CA64 = Phase B65 = Phase BN66 = Phase BC128 = Phase A (and S1)129 = Phase AN (and S1N)132 = Phase AB224 = Phase ABCAll other values reserved.
See definition for values
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 207 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
of these values. 6487
accumulationBehaviour attribute (AccumulationBehaviourType) [0..1] 6488 The “accumulation behaviour” indicates how the value is represented to accumulate over time. 6489
calorificValue attribute (UnitValueType) [0..1] 6490 The amount of heat generated when a given mass of fuel is completely burned. The CalorificValue is used 6491 to convert the measured volume or mass of gas into kWh. The CalorificValue attribute represents the 6492 current active value. 6493
commodity attribute (CommodityType) [0..1] 6494 Indicates the commodity applicable to this ReadingType. 6495
conversionFactor attribute (UnitValueType) [0..1] 6496 Accounts for changes in the volume of gas based on temperature and pressure. The ConversionFactor 6497 attribute represents the current active value. The ConversionFactor is dimensionless. The default value for 6498 the ConversionFactor is 1, which means no conversion is applied. A price server can advertise a 6499 new/different value at any time. 6500
dataQualifier attribute (DataQualifierType) [0..1] 6501 The data type can be used to describe a salient attribute of the data. Possible values are average, absolute, 6502 and etc. 6503
flowDirection attribute (FlowDirectionType) [0..1] 6504 Anything involving current might have a flow direction. Possible values include forward and reverse. 6505
intervalLength attribute (UInt32) [0..1] 6506 Default interval length specified in seconds. 6507
kind attribute (KindType) [0..1] 6508 Compound class that contains kindCategory and kindIndex 6509
maxNumberOfIntervals attribute (UInt8) [0..1] 6510 To be populated for mirrors of interval data to set the expected number of intervals per ReadingSet. 6511 Servers may discard intervals received that exceed this number. 6512
numberOfConsumptionBlocks attribute (UInt8) [0..1] 6513 Number of consumption blocks. 0 means not applicable, and is the default if not specified. The value 6514 needs to be at least 1 if any actual prices are provided. 6515
numberOfTouTiers attribute (UInt8) [0..1] 6516 The number of TOU tiers that can be used by any resource configured by this ReadingType. Servers 6517 SHALL populate this value with the largest touTier value that will ever be used while this ReadingType 6518 is in effect. Servers SHALL set numberOfTouTiers equal to the number of standard TOU tiers plus the 6519 number of CPP tiers that may be used while this ReadingType is in effect. Servers SHALL specify a 6520 value between 1 and 255 (inclusive) for numberOfTouTiers (servers providing flat rate pricing SHALL 6521 set numberOfTouTiers to 1, as in practice there is no difference between having no tiers and having one 6522 tier). 6523
phase attribute (PhaseCode) [0..1] 6524 Contains phase information associated with the type. 6525
powerOfTenMultiplier attribute (PowerOfTenMultiplierType) [0..1] 6526 Indicates the power of ten multiplier applicable to the unit of measure of this ReadingType. 6527
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 208 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
subIntervalLength attribute (UInt32) [0..1] 6528 Default sub-interval length specified in seconds for Readings of ReadingType. Some demand calculations 6529 are done over a number of smaller intervals. For example, in a rolling demand calculation, the demand 6530 value is defined as the rolling sum of smaller intervals over the intervalLength. The subintervalLength is 6531 the length of the smaller interval in this calculation. It SHALL be an integral division of the 6532 intervalLength. The number of sub-intervals can be calculated by dividing the intervalLength by the 6533 subintervalLength. 6534
supplyLimit attribute (UInt48) [0..1] 6535 Reflects the supply limit set in the meter. This value can be compared to the Reading value to understand 6536 if limits are being approached or exceeded. Units follow the same definition as in this ReadingType. 6537
tieredConsumptionBlocks attribute (boolean) [0..1] 6538 Specifies whether or not the consumption blocks are differentiated by TOUTier or not. Default is false, if 6539 not specified. 6540
true = consumption accumulated over individual tiers 6541
false = consumption accumulated over all tiers 6542
uom attribute (UomType) [0..1] 6543 Indicates the measurement type for the units of measure for the readings of this type. 6544
UsagePoint Object (UsagePointBase) 6545 Logical point on a network at which consumption or production is either physically measured 6546 (e.g. metered) or estimated (e.g. unmetered street lights). 6547
UsagePointList Object (SubscribableList) 6548 A List element to hold UsagePoint objects. 6549
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 209 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
15.1.15.1 Metering Mirror Package 6550
6551
6552
Figure 15-25: Metering Mirror 6553
class Metering Mirror
ListMirrorUsagePointList
UsagePointBaseMirrorUsagePoint
+ deviceLFDI :HexBinary160
MeterReadingBaseMirrorMeterReading
+ lastUpdateTime :TimeType [0..1]+ nextUpdateTime :TimeType [0..1]::IdentifiedObject+ description :String32 [0..1]+ mRID :mRIDType+ version :VersionType [0..1] = 0
«XSDattribute»::Resource+ href :anyURI [0..1]
ResourceReadingType
ListLinkMirrorUsagePointListLink
FunctionSetAssignmentsBaseDev iceCapability
ReadingBaseReading
+ localID :HexBinary16 [0..1]
«XSDattribute»+ subscribable :SubscribableType [0..1] = 0
ReadingSetBaseMirrorReadingSet
::ReadingSetBase+ timePeriod :DateTimeInterval::IdentifiedObject+ description :String32 [0..1]+ mRID :mRIDType+ version :VersionType [0..1] = 0
«XSDattribute»::Resource+ href :anyURI [0..1]
ListMirrorMeterReadingList
0..*
0..*
0..1
0..1
0..*
0..1
0..*
0..*
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 210 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
6554
Figure 15-26: Metering Mirror Inheritance 6555
MirrorMeterReading Object (MeterReadingBase) 6556 Mimic of MeterReading used for managing mirrors. 6557
lastUpdateTime attribute (TimeType) [0..1] 6558 The date and time of the last update. 6559
nextUpdateTime attribute (TimeType) [0..1] 6560 The date and time of the next planned update. 6561
MirrorMeterReadingList Object (List) 6562 A List of MirrorMeterReading instances. 6563
MeterReadingBase Object (IdentifiedObject) 6564 A container for associating ReadingType, Readings and ReadingSets. 6565
MirrorReadingSet Object (ReadingSetBase) 6566 A set of Readings of the ReadingType indicated by the parent MeterReading. 6567
MirrorUsagePoint Object (UsagePointBase) 6568 A parallel to UsagePoint to support mirroring 6569
deviceLFDI attribute (HexBinary160) 6570
class Metering Mirror Inheritance
MeterReadingUsagePoint
MeterReadingBaseUsagePointBase
+ roleFlags :RoleFlagsType+ serviceCategoryKind :ServiceKind+ status :UInt8
MirrorMeterReading
+ lastUpdateTime :TimeType [0..1]+ nextUpdateTime :TimeType [0..1]
MirrorUsagePoint
+ deviceLFDI :HexBinary160
ResourceIdentifiedObject
+ description :String32 [0..1]+ mRID :mRIDType+ version :VersionType [0..1] = 0
Reading
+ localID :HexBinary16 [0..1]
«XSDattribute»+ subscribable :SubscribableType [0..1] = 0
ResourceReadingBase
+ consumptionBlock :ConsumptionBlockType [0..1] = 0+ qualityFlags :HexBinary16 [0..1] = 00+ timePeriod :DateTimeInterval [0..1]+ touTier :TOUType [0..1] = 0+ value :Int48 [0..1]
ReadingSet
ReadingSetBase
+ timePeriod :DateTimeInterval
MirrorReadingSet
BillingReading
0..1
0..*
0..*
0..*
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 211 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
The LFDI of the device being mirrored. 6571
MirrorUsagePointList Object (List) 6572 A List of MirrorUsagePoint instances. 6573
ReadingBase Object (Resource) 6574 Specific value measured by a meter or other asset. ReadingBase is abstract, used to define the 6575 elements common to Reading and IntervalReading. 6576
consumptionBlock attribute (ConsumptionBlockType) [0..1] 6577 Indicates the consumption block related to the reading. REQUIRED if ReadingType 6578 numberOfConsumptionBlocks is non-zero. If not specified, is assumed to be "0 - N/A". 6579
qualityFlags attribute (HexBinary16) [0..1] 6580 List of codes indicating the quality of the reading, using specification: 6581
Bit 0 - valid: data that has gone through all required validation checks and either passed them all or has 6582 been verified 6583
Bit 1 - manually edited: Replaced or approved by a human 6584
Bit 2 - estimated using reference day: data value was replaced by a machine computed value based on 6585 analysis of historical data using the same type of measurement. 6586
Bit 3 - estimated using linear interpolation: data value was computed using linear interpolation based on 6587 the readings before and after it 6588
Bit 4 - questionable: data that has failed one or more checks 6589
Bit 5 - derived: data that has been calculated (using logic or mathematical operations), not necessarily 6590 measured directly 6591
Bit 6 - projected (forecast): data that has been calculated as a projection or forecast of future readings 6592
timePeriod attribute (DateTimeInterval) [0..1] 6593 The time interval associated with the reading. If not specified, then defaults to the intervalLength 6594 specified in the associated ReadingType. 6595
touTier attribute (TOUType) [0..1] 6596 Indicates the time of use tier related to the reading. REQUIRED if ReadingType numberOfTouTiers is 6597 non-zero. If not specified, is assumed to be "0 - N/A". 6598
value attribute (Int48) [0..1] 6599 Value in units specified by ReadingType 6600
ReadingSetBase Object (IdentifiedObject) 6601 A set of Readings of the ReadingType indicated by the parent MeterReading. ReadingBase is 6602 abstract, used to define the elements common to ReadingSet and IntervalBlock. 6603
timePeriod attribute (DateTimeInterval) 6604 Specifies the time range during which the contained readings were taken. 6605
UsagePointBase Object (IdentifiedObject) 6606 Logical point on a network at which consumption or production is either physically measured 6607 (e.g. metered) or estimated (e.g. unmetered street lights). A container for associating 6608 ReadingType, Readings and ReadingSets. 6609
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 212 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
roleFlags attribute (RoleFlagsType) 6610 Specifies the roles that apply to the usage point. 6611
serviceCategoryKind attribute (ServiceKind) 6612 The kind of service provided by this usage point. 6613
status attribute (UInt8) 6614 Specifies the current status of the service at this usage point. 6615
0 = off 6616
1 = on 6617
15.1.16 Pricing Package 6618
Contains definitions of information related to price. 6619
6620
Figure 15-27: Pricing 6621
ConsumptionTariffInterval Object (Resource) 6622 One of a sequence of thresholds defined in terms of consumption quantity of a service such as 6623 electricity, water, gas, etc. It defines the steps or blocks in a step tariff structure, where startValue 6624
Pricing
Env ironmentalCost
+ amount :UInt32+ costKind :CostKindType+ costLevel :UInt8+ numCostLevels :UInt8
RandomizableEventTimeTariffInterv al
+ touTier :TOUType::RandomizableEvent+ randomizeDuration :OneHourRangeType [0..1] = 0+ randomizeStart :OneHourRangeType [0..1] = 0::Event+ creationTime :TimeType+ interval :DateTimeInterval::RespondableSubscribableIdentifiedObject+ description :String32 [0..1]+ mRID :mRIDType+ version :VersionType [0..1] = 0
«XSDattribute»::RespondableSubscribableIdentifiedObject+ subscribable :SubscribableType [0..1] = 0::RespondableResource+ replyTo :anyURI [0..1]+ responseRequired :HexBinary8 [0..1] = 00::Resource+ href :anyURI [0..1]
ResourceConsumptionTariffInterv al
+ consumptionBlock :ConsumptionBlockType+ price :Int32 [0..1]+ startValue :UInt48
«XSDattribute»::Resource+ href :anyURI [0..1]
IdentifiedObjectTariffProfile
+ currency :CurrencyCode [0..1]+ pricePowerOfTenMultiplier :PowerOfTenMultiplierType [0..1]+ primacy :PrimacyType+ rateCode :String20 [0..1]+ serviceCategoryKind :ServiceKind::IdentifiedObject+ description :String32 [0..1]+ mRID :mRIDType+ version :VersionType [0..1] = 0
«XSDattribute»::Resource+ href :anyURI [0..1]
ResourceFunctionSetAssignmentsBase
IdentifiedObjectRateComponent
+ flowRateEndLimit :UnitValueType [0..1]+ flowRateStartLimit :UnitValueType [0..1]+ roleFlags :RoleFlagsType::IdentifiedObject+ description :String32 [0..1]+ mRID :mRIDType+ version :VersionType [0..1] = 0
«XSDattribute»::Resource+ href :anyURI [0..1]
UInt8CostKindType
notes0 - Carbon Dioxide emissions, in grams per unit1 - Sulfur Dioxide emissions, in grams per unit2 - Nitrogen Oxides emissions, in grams per unit3 - Renewable generation, as a percentage of overall generationAll other values reserved.
LinkReadingTypeLink
ListLinkRateComponentListLink
ListLinkTimeTariffInterv alListLink
ListLinkActiv eTimeTariffInterv alListLink
UnitValueType
+ multiplier :PowerOfTenMultiplierType+ unit :UomType+ value :Int32
ListLinkTariffProfileListLink
ListLinkConsumptionTariffInterv alListLink
ListConsumptionTariffInterv alList
0..1
0..*
0..1
0..1
0..1
1
0..1
1..*
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 213 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
simultaneously defines the entry value of this step and the closing value of the previous step. 6625 Where consumption is greater than startValue, it falls within this block and where consumption is 6626 less than or equal to startValue, it falls within one of the previous blocks. 6627
consumptionBlock attribute (ConsumptionBlockType) 6628 Indicates the consumption block related to the reading. If not specified, is assumed to be "0 - N/A". 6629
price attribute (Int32) [0..1] 6630 The charge for this rate component, per unit of measure defined by the associated ReadingType, in 6631 currency specified in TariffProfile. 6632
The Pricing service provider determines the appropriate price attribute value based on its applicable 6633 regulatory rules. For example, price could be net or inclusive of applicable taxes, fees, or levies. 6634
The Billing function set provides the ability to represent billing information in a more detailed manner. 6635
startValue attribute (UInt48) 6636 The lowest level of consumption that defines the starting point of this consumption step or block. 6637 Thresholds start at zero for each billing period. 6638
If specified, the first ConsumptionTariffInterval.startValue for a TimeTariffInteral instance SHALL begin 6639 at "0." Subsequent ConsumptionTariffInterval.startValue elements SHALL be greater than the previous 6640 one. 6641
ConsumptionTariffIntervalList Object (List) 6642 A List element to hold ConsumptionTariffInterval objects. 6643
CostKindType Object (UInt8) 6644 0 - Carbon Dioxide emissions, in grams per unit 6645
1 - Sulfur Dioxide emissions, in grams per unit 6646
2 - Nitrogen Oxides emissions, in grams per unit 6647
3 - Renewable generation, as a percentage of overall generation 6648
All other values reserved. 6649
EnvironmentalCost Object () 6650 Provides alternative or secondary price information for the relevant RateComponent. Supports 6651 jurisdictions that seek to convey the environmental price per unit of the specified commodity not 6652 expressed in currency. 6653
Implementers and consumers can use this attribute to prioritize operations of their HAN devices 6654 (e.g., PEV charging during times of high availability of renewable electricity resources). 6655
amount attribute (UInt32) 6656 The estimated or actual environmental or other cost, per commodity unit defined by the ReadingType, for 6657 this RateComponent (e.g., grams of carbon dioxide emissions each per kWh). 6658
costKind attribute (CostKindType) 6659 The kind of cost referred to in the amount. 6660
costLevel attribute (UInt8) 6661
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 214 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
The relative level of the amount attribute. In conjunction with numCostLevels, this attribute informs a 6662 device of the relative scarcity of the amount attribute (e.g., a high or low availability of renewable 6663 generation). 6664
numCostLevels and costLevel values SHALL ascend in order of scarcity, where "0" signals the lowest 6665 relative cost and higher values signal increasing cost. For example, if numCostLevels is equal to “3,” 6666 then if the lowest relative costLevel were equal to “0,” devices would assume this is the lowest relative 6667 period to operate. Likewise, if the costLevel in the next TimeTariffInterval instance is equal to “1,” then 6668 the device would assume it is relatively more expensive, in environmental terms, to operate during this 6669 TimeTariffInterval instance than the previous one. 6670
There is no limit to the number of relative price levels other than that indicated in the attribute type, but 6671 for practicality, service providers should strive for simplicity and recognize the diminishing returns 6672 derived from increasing the numCostLevel value greater than four. 6673
numCostLevels attribute (UInt8) 6674 The number of all relative cost levels. 6675
In conjunction with costLevel, numCostLevels signals the relative scarcity of the commodity for the 6676 duration of the TimeTariffInterval instance (e.g., a relative indication of cost). This is useful in providing 6677 context for nominal cost signals to consumers or devices that might see a range of amount values from 6678 different service providres or from the same service provider. 6679
RateComponent Object (IdentifiedObject) 6680 Specifies the applicable charges for a single component of the rate, which could be generation 6681 price or consumption price, for example. 6682
flowRateEndLimit attribute (UnitValueType) [0..1] 6683 Specifies the maximum flow rate (e.g. kW for electricity) for which this RateComponent applies, for the 6684 usage point and given rate / tariff. 6685
In combination with flowRateStartLimit, allows a service provider to define the demand or output 6686 characteristics for the particular tariff design. If a server includes the flowRateEndLimit attribute, then it 6687 SHALL also include flowRateStartLimit attribute. 6688
For example, a service provider’s tariff limits customers to 20 kWs of demand for the given rate structure. 6689 Above this threshold (from 20-50 kWs), there are different demand charges per unit of consumption. The 6690 service provider can use flowRateStartLimit and flowRateEndLimit to describe the demand 6691 characteristics of the different rates. Similarly, these attributes can be used to describe limits on premises 6692 DERs that might be producing a commodity and sending it back into the distribution network. 6693
Note: At the time of writing, service provider tariffs with demand-based components were not originally 6694 identified as being in scope, and service provider tariffs vary widely in their use of demand components 6695 and the method for computing charges. It is expected that industry groups (e.g., OpenSG) will document 6696 requirements in the future that the SEP 2.0 community can then use as source material for the next 6697 version of SEP 2.0. 6698
flowRateStartLimit attribute (UnitValueType) [0..1] 6699 Specifies the minimum flow rate (e.g., kW for electricity) for which this RateComponent applies, for the 6700 usage point and given rate / tariff. 6701
In combination with flowRateEndLimit, allows a service provider to define the demand or output 6702 characteristics for the particular tariff design. If a server includes the flowRateStartLimit attribute, then it 6703
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 215 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
SHALL also include flowRateEndLimit attribute. 6704
roleFlags attribute (RoleFlagsType) 6705 Specifies the roles that this usage point has been assigned. 6706
RateComponentList Object (List) 6707 A List element to hold RateComponent objects. 6708
TariffProfile Object (IdentifiedObject) 6709 A schedule of charges; structure that allows the definition of tariff structures such as step (block) 6710 and time of use (tier) when used in conjunction with TimeTariffInterval and 6711 ConsumptionTariffInterval. 6712
currency attribute (CurrencyCode) [0..1] 6713 The currency code indicating the currency for this TariffProfile. 6714
pricePowerOfTenMultiplier attribute (PowerOfTenMultiplierType) [0..1] 6715 Indicates the power of ten multiplier for the price attribute. 6716
primacy attribute (PrimacyType) 6717 Indicates the relative primacy of the provider of this program. 6718
rateCode attribute (String20) [0..1] 6719 The rate code for this tariff profile. Provided by the Pricing service provider per its internal business 6720 needs and practices and provides a method to identify the specific rate code for the TariffProfile instance. 6721 This would typically not be communicated to the user except to facilitate troubleshooting due to its 6722 service provider-specific technical nature. 6723
serviceCategoryKind attribute (ServiceKind) 6724 The kind of service provided by this usage point. 6725
TariffProfileList Object (SubscribableList) 6726 A List element to hold TariffProfile objects. 6727
TimeTariffInterval Object (RandomizableEvent) 6728 Describes the time-differentiated portion of the RateComponent, if applicable, and provides the 6729 ability to specify multiple time intervals, each with its own consumption-based components and 6730 other attributes. 6731
touTier attribute (TOUType) 6732 Indicates the time of use tier related to the reading. If not specified, is assumed to be "0 - N/A". 6733
TimeTariffIntervalList Object (SubscribableList) 6734 A List element to hold TimeTariffInterval objects. 6735
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 216 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
15.1.17 Messaging Package 6736
Contains text message definitions. 6737
6738
Figure 15-28: TextMessage 6739
MessagingProgram Object (SubscribableIdentifiedObject) 6740 Provides a container for collections of text messages. 6741
locale attribute (LocaleType) 6742 Indicates the language and region of the messages in this collection. 6743
primacy attribute (PrimacyType) 6744 Indicates the relative primacy of the provider of this program. 6745
class TextMessage
ResourceFunctionSetAssignmentsBase
EventTextMessage
+ originator :String20 [0..1]+ priority :PriorityType+ textMessage :string::Event+ creationTime :TimeType+ interval :DateTimeInterval::RespondableSubscribableIdentifiedObject+ description :String32 [0..1]+ mRID :mRIDType+ version :VersionType [0..1] = 0
«XSDattribute»::RespondableSubscribableIdentifiedObject+ subscribable :SubscribableType [0..1] = 0::RespondableResource+ replyTo :anyURI [0..1]+ responseRequired :HexBinary8 [0..1] = 00::Resource+ href :anyURI [0..1]
UInt8PriorityType
notesIndicates the priority of a message:0 - Low1 - Normal2 - High3 - CriticalAll other values reserved.
ListLinkTextMessageListLink
ListLinkActiv eTextMessageListLink
SubscribableIdentifiedObjectMessagingProgram
+ locale :LocaleType+ primacy :PrimacyType
ListLinkMessagingProgramListLink
SubscribableListTextMessageList
SubscribableListMessagingProgramList
0..1
0..10..1
0..*0..*
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 217 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
MessagingProgramList Object (SubscribableList) 6746 A List element to hold MessagingProgram objects. 6747
PriorityType Object (UInt8) 6748 Indicates the priority of a message: 6749
0 - Low 6750
1 - Normal 6751
2 - High 6752
3 - Critical 6753
All other values reserved. 6754
TextMessage Object (Event) 6755 Text message such as a notification. 6756
originator attribute (String20) [0..1] 6757 Indicates the human-readable name of the publisher of the message 6758
priority attribute (PriorityType) 6759 The priority is used to inform the client of the priority of the particular message. Devices with 6760 constrained or limited resources for displaying Messages should use this attribute to determine how to 6761 handle displaying currently active Messages (e.g. if a device uses a scrolling method with a single 6762 Message viewable at a time it MAY want to push a low priority Message to the background and bring a 6763 newly received higher priority Message to the foreground). 6764
textMessage attribute (string) 6765 The textMessage attribute contains the actual UTF-8 encoded text to be displayed in conjunction with the 6766 messageLength attribute which contains the overall length of the textMessage attribute. Clients and 6767 servers SHALL support a reception of a Message of 100 bytes in length. Messages that exceed the clients 6768 display size will be left to the client to choose what method to handle the message (truncation, scrolling, 6769 etc.). 6770
TextMessageList Object (SubscribableList) 6771 A List element to hold TextMessage objects. 6772
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 218 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
15.1.18 Billing Package 6773
Contains representations of charges and other billing related information. 6774
6775
Figure 15-29: Billing 6776
Billing
IdentifiedObjectCustomerAccount
+ currency :UInt16+ customerAccount :String42 [0..1]+ customerName :String42 [0..1]+ pricePowerOfTenMultiplier :PowerOfTenMultiplierType::IdentifiedObject+ description :String32 [0..1]+ mRID :mRIDType+ version :VersionType [0..1] = 0
«XSDattribute»::Resource+ href :anyURI [0..1]
ResourceBillingPeriod
+ billLastPeriod :Int48 [0..1]+ bil lToDate :Int48 [0..1]+ interval :DateTimeInterval+ statusTimeStamp :TimeType [0..1]
«XSDattribute»::Resource+ href :anyURI [0..1]
ListLinkBillingPeriodListLinkResource
FunctionSetAssignmentsBase
ListLinkCustomerAccountListLink
SubscribableListCustomerAccountList
SubscribableListBillingPeriodList
IdentifiedObjectCustomerAgreement
+ serviceAccount :String42 [0..1]+ serviceLocation :String42 [0..1]
IdentifiedObjectServ iceSupplier
+ email :String32 [0..1]+ phone :String20 [0..1]+ providerID :UInt32 [0..1]+ web :String42 [0..1]
ListLinkCustomerAgreementListLink
SubscribableListCustomerAgreementList
LinkServ iceSupplierLink
LinkUsagePointLink
LinkPrepaymentLink
LinkTariffProfileLink
0..10..1
0..1
0..*
0..*
0..10..10..10..1
0..*
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 219 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
6777
Figure 15-30: Billing Readings 6778
BillingPeriod Object (Resource) 6779 A Billing Period relates to the period of time on which a customer is billed. As an example the 6780 billing period interval for a particular customer might be 31 days starting on July 1, 2011. The 6781 start date and interval can change on each billing period. There may also be multiple billing 6782 periods related to a customer agreement to support different tariff structures. 6783
billLastPeriod attribute (Int48) [0..1] 6784 The amount of the bill for the previous billing period. 6785
billToDate attribute (Int48) [0..1] 6786 The bill amount related to the billing period as of the statusTimeStamp. 6787
interval attribute (DateTimeInterval) 6788 The time interval for this billing period. 6789
statusTimeStamp attribute (TimeType) [0..1] 6790 The date / time of the last update of this resource. 6791
BillingPeriodList Object (SubscribableList) 6792 A List element to hold BillingPeriod objects. 6793
class Billing Readings
Charge
+ description :String20 [0..1]+ kind :ChargeKind [0..1]+ value :Int32
ProjectionReadingTargetReadingHistoricalReading
UInt8ChargeKind
notesKind of charge.0 - Consumption Charge1 - Rebate 2 - Auxiliary Charge3 - Demand Charge4 - Tax Charge
ListLinkTargetReadingListLink
ListLinkProjectionReadingListLink
ListLinkHistoricalReadingListLink
IdentifiedObjectCustomerAgreement
+ serviceAccount :String42 [0..1]+ serviceLocation :String42 [0..1]
BillingReading
BillingReadingSet
IdentifiedObjectMeterReadingBase
::IdentifiedObject+ description :String32 [0..1]+ mRID :mRIDType+ version :VersionType [0..1] = 0
«XSDattribute»::Resource+ href :anyURI [0..1]
LinkReadingTypeLink BillingMeterReadingBase
SubscribableListBillingReadingSetList
ListLinkBillingReadingSetListLink
ResourceReadingBase
+ consumptionBlock :ConsumptionBlockType [0..1] = 0+ qualityFlags :HexBinary16 [0..1] = 00+ timePeriod :DateTimeInterval [0..1]+ touTier :TOUType [0..1] = 0+ value :Int48 [0..1]
IdentifiedObjectReadingSetBase
+ timePeriod :DateTimeInterval
ListHistoricalReadingList
ListTargetReadingList
ListProjectionReadingList
ListBillingReadingList
ListLinkBillingReadingListLink
0..*0..*0..*
0..*
0..1 0..1
0..*
0..1
0..*
0..10..10..1
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 220 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
BillingMeterReadingBase Object (MeterReadingBase) 6794 Contains historical, target, and projection readings of various types, possibly associated with 6795 charges. 6796
BillingReading Object (ReadingBase) 6797 Data captured at regular intervals of time. Interval data could be captured as incremental data, 6798 absolute data, or relative data. The source for the data is usually a tariff quantity or an engineering 6799 quantity. Data is typically captured in time-tagged, uniform, fixed-length intervals of 5 min, 10 6800 min, 15 min, 30 min, or 60 min. However, consumption aggregations can also be represented 6801 with this class. 6802
BillingReadingList Object (List) 6803 A List element to hold BillingReading objects. 6804
BillingReadingSet Object (ReadingSetBase) 6805 Time sequence of readings of the same reading type. 6806
BillingReadingSetList Object (SubscribableList) 6807 A List element to hold BillingReadingSet objects. 6808
Charge Object () 6809 Charges contain charges on a customer bill. These could be items like taxes, levies, surcharges, 6810 rebates, or others. This is meant to allow the HAN device to retrieve enough information to be 6811 able to reconstruct an estimate of what the total bill would look like. 6812
Providers can provide line item billing, including multiple charge kinds (e.g. taxes, surcharges) at 6813 whatever granularity desired, using as many Charges as desired during a billing period. There can 6814 also be any number of Charges associated with different ReadingTypes to distinguish between 6815 TOU tiers, consumption blocks, or demand charges. 6816
description attribute (String20) [0..1] 6817 A description of the charge. 6818
kind attribute (ChargeKind) [0..1] 6819 The type (kind) of charge. 6820
value attribute (Int32) 6821 A monetary charge. 6822
ChargeKind Object (UInt8) 6823 Kind of charge. 6824
0 - Consumption Charge 6825
1 - Rebate 6826
2 - Auxiliary Charge 6827
3 - Demand Charge 6828
4 - Tax Charge 6829
CustomerAccount Object (IdentifiedObject) 6830 Assignment of a group of products and services purchased by the Customer through a 6831 CustomerAgreement, used as a mechanism for customer billing and payment. It contains common 6832 information from the various types of CustomerAgreements to create billings (invoices) for a 6833
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 221 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Customer and receive payment. 6834
currency attribute (UInt16) 6835 The ISO 4217 code indicating the currency applicable to the bill amounts in the summary. See list at 6836 http://www.unece.org/cefact/recommendations/rec09/rec09_ecetrd203.pdf 6837
customerAccount attribute (String42) [0..1] 6838 The account number for the customer (if applicable). 6839
customerName attribute (String42) [0..1] 6840 The name of the customer. 6841
pricePowerOfTenMultiplier attribute (PowerOfTenMultiplierType) 6842 Indicates the power of ten multiplier for the prices in this function set. 6843
CustomerAccountList Object (SubscribableList) 6844 A List element to hold CustomerAccount objects. 6845
CustomerAgreement Object (IdentifiedObject) 6846 Agreement between the customer and the service supplier to pay for service at a specific service 6847 location. It records certain billing information about the type of service provided at the service 6848 location and is used during charge creation to determine the type of service. 6849
serviceAccount attribute (String42) [0..1] 6850 The account number of the service account (if applicable). 6851
serviceLocation attribute (String42) [0..1] 6852 The address or textual description of the service location. 6853
CustomerAgreementList Object (SubscribableList) 6854 A List element to hold CustomerAgreement objects. 6855
HistoricalReading Object (BillingMeterReadingBase) 6856 To be used to present readings that have been processed and possibly corrected (as allowed, due 6857 to missing or incorrect data) by backend systems. This includes quality codes valid, verified, 6858 estimated, and derived / corrected. 6859
HistoricalReadingList Object (List) 6860 A List element to hold HistoricalReading objects. 6861
ProjectionReading Object (BillingMeterReadingBase) 6862 Contains values that forecast a future reading for the time or interval specified. 6863
ProjectionReadingList Object (List) 6864 A List element to hold ProjectionReading objects. 6865
TargetReading Object (BillingMeterReadingBase) 6866 Contains readings that specify a target or goal, such as a consumption target, to which billing 6867 incentives or other contractual ramifications may be associated. 6868
TargetReadingList Object (List) 6869 A List element to hold TargetReading objects. 6870
ServiceSupplier Object (IdentifiedObject) 6871 Organisation that provides services to Customers. 6872
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 222 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
email attribute (String32) [0..1] 6873 E-mail address for this service supplier. 6874
phone attribute (String20) [0..1] 6875 Human-readable phone number for this service supplier. 6876
providerID attribute (UInt32) [0..1] 6877 Contains the IANA PEN for the commodity provider. 6878
web attribute (String42) [0..1] 6879 Website URI address for this service supplier. 6880
ServiceSupplierList Object (List) 6881 A List element to hold ServiceSupplier objects. 6882
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 223 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
15.1.19 Prepayment Package 6883
Contains definitions related to storing and using payments. 6884
6885
Figure 15-31: Prepayment 6886
class Prepayment
AccountingUnit
+ energyUnit :RealEnergy [0..1]+ monetaryUnit :CurrencyCode+ multiplier :PowerOfTenMultiplierType+ value :Int32
RealEnergy
+ multiplier :PowerOfTenMultiplierType+ value :UInt48
IdentifiedObjectCreditRegister
+ creditAmount :AccountingUnit+ creditType :CreditTypeType [0..1]+ effectiveTime :TimeType+ token :String32
IdentifiedObjectPrepayment
+ creditExpiryLevel :AccountingUnit [0..1]+ lowCreditWarningLevel :AccountingUnit [0..1]+ lowEmergencyCreditWarningLevel :AccountingUnit [0..1]+ prepayMode :PrepayModeType
UInt8CreditTypeType
notes0 - Regular1 - Emergency2 - Regular, then Emergency3 - Emergency, then RegularAll other values reserved.
UInt8CreditStatusType
notes0 - Credit Ok1 - Credit Low2 - Credit Exhausted3 - Credit NegativeAll other values reserved.
UInt8PrepayModeType
notes0 - Central Wallet1 - ESI2 - Local3 - CreditAll other values reserved.
UInt8Serv iceStatusType
notes0 - Connected1 - Disconnected2 - Armed for Connect3 - Armed for Disconnect4 - No Contactor5 - Load LimitedAll other values reserved.
ResourceSupplyInterruptionOv erride
+ description :String32 [0..1]+ interval :DateTimeInterval
Serv iceChange
+ newStatus :ServiceStatusType+ startTime :TimeType
CreditTypeChange
+ newType :CreditTypeType+ startTime :TimeType
ResourceAccountBalance
+ availableCredit :AccountingUnit+ creditStatus :CreditStatusType [0..1]+ emergencyCredit :AccountingUnit [0..1]+ emergencyCreditStatus :CreditStatusType [0..1]
ResourcePrepayOperationStatus
+ creditTypeChange :CreditTypeChange [0..1]+ creditTypeInUse :CreditTypeType [0..1]+ serviceChange :ServiceChange [0..1]+ serviceStatus :ServiceStatusType
ListLinkCreditRegisterListLink
ListLinkSupplyInterruptionOv errideListLink
LinkAccountBalanceLink
LinkPrepayOperationStatusLink
ResourceFunctionSetAssignmentsBase
ListLinkPrepaymentListLink
SubscribableListPrepaymentList
LinkUsagePointLink
ListCreditRegisterList
ListSupplyInterruptionOv errideList
1
1
0..11
1
0..1
0..*
0..* 0..*
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 224 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
AccountBalance Object (Resource) 6887 AccountBalance contains the regular credit and emergency credit balance for this given service or 6888 commodity prepay instance. It may also contain status information concerning the balance data. 6889
availableCredit attribute (AccountingUnit) 6890 AvailableCredit shows the balance of the sum of credits minus the sum of charges. In a Central Wallet 6891 mode this value may be passed down to the Prepayment server via an out-of-band mechanism. In Local or 6892 ESI modes, this value may be calculated based upon summation of CreditRegister transactions minus 6893 consumption charges calculated using Metering (and possibly Pricing) function set data. This value may 6894 be negative; for instance, if disconnection is prevented due to a Supply Interruption Override. 6895
creditStatus attribute (CreditStatusType) [0..1] 6896 CreditStatus identifies whether the present value of availableCredit is considered OK, low, exhausted, or 6897 negative. 6898
emergencyCredit attribute (AccountingUnit) [0..1] 6899 EmergencyCredit is the amount of credit still available for the given service or commodity prepayment 6900 instance. If both availableCredit and emergyCredit are exhausted, then service will typically be 6901 disconnected. 6902
emergencyCreditStatus attribute (CreditStatusType) [0..1] 6903 EmergencyCreditStatus identifies whether the present value of emergencyCredit is considered OK, low, 6904 exhausted, or negative. 6905
AccountingUnit Object () 6906 Unit for accounting; use either 'energyUnit' or 'currencyUnit' to specify the unit for 'value'. 6907
energyUnit attribute (RealEnergy) [0..1] 6908 Unit of service. 6909
monetaryUnit attribute (CurrencyCode) 6910 Unit of currency. 6911
multiplier attribute (PowerOfTenMultiplierType) 6912 Multiplier for the 'energyUnit' or 'monetaryUnit'. 6913
value attribute (Int32) 6914 Value of the monetary aspect 6915
CreditRegister Object (IdentifiedObject) 6916 CreditRegister instances define a credit-modifying transaction. Typically this would be a credit-6917 adding transaction, but may be a subtracting transaction (perhaps in response to an out-of-band 6918 debt signal). 6919
creditAmount attribute (AccountingUnit) 6920 CreditAmount is the amount of credit being added by a particular CreditRegister transaction. Negative 6921 values indicate that credit is being subtracted. 6922
creditType attribute (CreditTypeType) [0..1] 6923 CreditType indicates whether the credit transaction applies to regular or emergency credit. 6924
effectiveTime attribute (TimeType) 6925 EffectiveTime identifies the time at which the credit transaction goes into effect. For credit addition 6926 transactions, this is typically the moment at which the transaction takes place. For credit subtraction 6927
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 225 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
transactions, (e.g., non-fuel debt recovery transactions initiated from a back-haul or ESI) this may be a 6928 future time at which credit is deducted. 6929
token attribute (String32) 6930 Token is security data that authenticates the legitimacy of the transaction. The details of this token are not 6931 defined by Smart Energy 2.0. How a Prepayment server handles this field is left as vendor specific 6932 implementation or will be defined by one or more other standards. 6933
CreditRegisterList Object (List) 6934 A List element to hold CreditRegister objects. 6935
Prepayment Object (IdentifiedObject) 6936 Prepayment (inherited from CIM SDPAccountingFunction) 6937
creditExpiryLevel attribute (AccountingUnit) [0..1] 6938 CreditExpiryLevel is the set point for availableCredit at which the service level may be changed. The 6939 typical value for this attribute is 0, regardless of whether the account balance is measured in a monetary 6940 or commodity basis. The units for this attribute SHALL match the units used for availableCredit. 6941
lowCreditWarningLevel attribute (AccountingUnit) [0..1] 6942 LowCreditWarningLevel is the set point for availableCredit at which the creditStatus attribute in the 6943 AccountBalance resource SHALL indicate that available credit is low. The units for this attribute SHALL 6944 match the units used for availableCredit. Typically, this value is set by the service provider. 6945
lowEmergencyCreditWarningLevel attribute (AccountingUnit) [0..1] 6946 LowEmergencyCreditWarningLevel is the set point for emergencyCredit at which the creditStatus 6947 attribute in the AccountBalance resource SHALL indicate that emergencycredit is low. The units for this 6948 attribute SHALL match the units used for availableCredit. Typically, this value is set by the service 6949 provider. 6950
prepayMode attribute (PrepayModeType) 6951 PrepayMode specifies whether the given Prepayment instance is operating in Credit, Central Wallet, ESI, 6952 or Local prepayment mode. The Credit mode indicates that prepayment is not presently in effect. The 6953 other modes are described in the Overview Section above. 6954
PrepaymentList Object (SubscribableList) 6955 A List element to hold Prepayment objects. 6956
PrepayModeType Object (UInt8) 6957 0 - Central Wallet 6958
1 - ESI 6959
2 - Local 6960
3 - Credit 6961
All other values reserved. 6962
PrepayOperationStatus Object (Resource) 6963 PrepayOperationStatus describes the status of the service or commodity being conditionally 6964 controlled by the Prepayment function set. 6965
creditTypeChange attribute (CreditTypeChange) [0..1] 6966 CreditTypeChange is used to define a pending change of creditTypeInUse, which will activate at a 6967
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 226 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
specified time. 6968
creditTypeInUse attribute (CreditTypeType) [0..1] 6969 CreditTypeInUse identifies whether the present mode of operation is consuming regular credit or 6970 emergency credit. 6971
serviceChange attribute (ServiceChange) [0..1] 6972 ServiceChange is used to define a pending change of serviceStatus, which will activate at a specified 6973 time. 6974
serviceStatus attribute (ServiceStatusType) 6975 ServiceStatus identifies whether the service is connected or disconnected, or armed for connection or 6976 disconnection. 6977
ServiceChange Object () 6978 Specifies a change to the service status. 6979
newStatus attribute (ServiceStatusType) 6980 The new service status, to take effect at the time specified by startTime 6981
startTime attribute (TimeType) 6982 The date/time when the change is to take effect. 6983
SupplyInterruptionOverride Object (Resource) 6984 SupplyInterruptionOverride: There may be periods of time when social, regulatory or other 6985 concerns mean that service should not be interrupted, even when available credit has been 6986 exhausted. Each Prepayment instance links to a List of SupplyInterruptionOverride instances. 6987 Each SupplyInterruptionOverride defines a contiguous period of time during which supply 6988 SHALL NOT be interrupted. 6989
description attribute (String32) [0..1] 6990 The description is a human readable text describing or naming the object. 6991
interval attribute (DateTimeInterval) 6992 Interval defines the period of time during which supply should not be interrupted. 6993
SupplyInterruptionOverrideList Object (List) 6994 A List element to hold SupplyInterruptionOverride objects. 6995
CreditStatusType Object (UInt8) 6996 0 - Credit Ok 6997
1 - Credit Low 6998
2 - Credit Exhausted 6999
3 - Credit Negative 7000
All other values reserved. 7001
CreditTypeType Object (UInt8) 7002 0 - Regular 7003
1 - Emergency 7004
2 - Regular, then Emergency 7005
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 227 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
3 - Emergency, then Regular 7006
All other values reserved. 7007
CreditTypeChange Object () 7008 Specifies a change to the credit type. 7009
newType attribute (CreditTypeType) 7010 The new credit type, to take effect at the time specified by startTime 7011
startTime attribute (TimeType) 7012 The date/time when the change is to take effect. 7013
ServiceStatusType Object (UInt8) 7014 0 - Connected 7015
1 - Disconnected 7016
2 - Armed for Connect 7017
3 - Armed for Disconnect 7018
4 - No Contactor 7019
5 - Load Limited 7020
All other values reserved. 7021
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 228 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
15.1.20 FlowReservation Package 7022
Contains flow (charge) reservation model to allow fine-grained control of high-demand loads such as fast-7023 charging batteries. 7024
7025
Figure 15-32: FlowReservation 7026
RequestStatus Object () 7027 The RequestStatus object is used to indicate the current status of a Flow Reservation Request. 7028
dateTime attribute (TimeType) 7029
class FlowReserv ation
ListLinkFlowReserv ationRequestListLink
AbstractDeviceEndDev ice
RealEnergy
+ multiplier :PowerOfTenMultiplierType+ value :UInt48
IdentifiedObjectFlowReserv ationRequest
+ creationTime :TimeType+ durationRequested :UInt16 [0..1]+ energyRequested :SignedRealEnergy+ intervalRequested :DateTimeInterval+ powerRequested :ActivePower::IdentifiedObject+ description :String32 [0..1]+ mRID :mRIDType+ version :VersionType [0..1] = 0
«XSDattribute»::Resource+ href :anyURI [0..1]
EventFlowReserv ationResponse
+ energyAvailable :RealEnergy+ powerAvailable :ActivePower+ subject :mRIDType::Event+ creationTime :TimeType+ interval :DateTimeInterval::RespondableSubscribableIdentifiedObject+ description :String32 [0..1]+ mRID :mRIDType+ version :VersionType [0..1] = 0
«XSDattribute»::RespondableSubscribableIdentifiedObject+ subscribable :SubscribableType [0..1] = 0::RespondableResource+ replyTo :anyURI [0..1]+ responseRequired :HexBinary8 [0..1] = 00::Resource+ href :anyURI [0..1]
ListLinkFlowReserv ationResponseListLink
ListFlowReserv ationRequestList
SubscribableListFlowReserv ationResponseList
Activ ePower
+ multiplier :PowerOfTenMultiplierType+ value :Int16
notesThe active (real) power P (in W) is the product of root-mean-square (RMS) voltage, RMS current, and cos(theta) where theta is the phaseangle of current relative to voltage. It is the primary measure of the rate of flow of energy.
RequestStatus
+ dateTime :TimeType+ requestStatus :UInt8
requestStatusField representing the request status type. 0 = Requested1 = CancelledAll other values reserved.
SignedRealEnergy
+ multiplier :PowerOfTenMultiplierType+ value :Int48
0..10..1
1
0..* 0..*
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 229 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
The dateTime attribute will provide a timestamp of when the request status was set. dateTime MUST be 7030 set to the time at which the status change occurred, not a time in the future or past. 7031
requestStatus attribute (UInt8) 7032 Field representing the request status type. 7033
0 = Requested 7034
1 = Cancelled 7035
All other values reserved. 7036
AbstractFlowReservation Object (Event) 7037 Provides definition of FlowReservation elements in common between Requests and Responses. 7038
FlowReservationRequest Object (IdentifiedObject) 7039 Used to request flow transactions. Client EndDevices submit a request for charging or 7040 discharging from the server. The server creates an associated FlowReservationResponse 7041 containing the charging parameters and interval to provide a lower aggregated demand at the 7042 premises, or within a larger part of the distribution system. 7043
creationTime attribute (TimeType) 7044 The time at which the request was created. 7045
durationRequested attribute (UInt16) [0..1] 7046 A value that is calculated by the storage device that defines the minimum duration, in seconds, that it will 7047 take to complete the actual flow transaction, including any ramp times and conditioning times, if 7048 applicable. 7049
energyRequested attribute (SignedRealEnergy) 7050 Indicates the total amount of energy, in Watt-Hours, requested to be transferred between the storage 7051 device and the electric power system. Positive values indicate charging and negative values indicate 7052 discharging. This sign convention is different than for the DER function where discharging is positive. 7053 Note that the energyRequestNow attribute in the PowerStatus Object must always represent a charging 7054 solution and it is not allowed to have a negative value. 7055
intervalRequested attribute (DateTimeInterval) 7056 The time window during which the flow reservation is needed. For example, if an electric vehicle is set 7057 with a 7:00 AM time charge is needed, and price drops to the lowest tier at 11:00 PM, then this window 7058 would likely be from 11:00 PM until 7:00 AM. 7059
powerRequested attribute (ActivePower) 7060 Indicates the sustained level of power, in Watts, that is requested. For charging this is calculated by the 7061 storage device and it represents the charging system capability (which for an electric vehicle must also 7062 account for any power limitations due to the EVSE control pilot). For discharging, a lower value than the 7063 inverter capability can be used as a target. 7064
FlowReservationRequestList Object (List) 7065 A List element to hold FlowReservationRequest objects. 7066
FlowReservationResponse Object (Event) 7067 The server may modify the charging or discharging parameters and interval to provide a lower 7068 aggregated demand at the premises, or within a larger part of the distribution system. 7069
energyAvailable attribute (RealEnergy) 7070
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 230 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Indicates the amount of energy available. 7071
powerAvailable attribute (ActivePower) 7072 Indicates the amount of power available. 7073
subject attribute (mRIDType) 7074 The subject field provides a method to match the response with the originating event. It is populated with 7075 the mRID of the corresponding FlowReservationRequest object. 7076
FlowReservationResponseList Object (SubscribableList) 7077 A List element to hold FlowReservationResponse objects. 7078
15.1.21 DER Package 7079
Contains definitions related to allowing distributed energy resources to provide energy back to the grid. 7080
7081
Figure 15-33: DER Info 7082
class DER Info
LinkDERStatusLink
SubscribableResourceDERStatus
+ genConnectStatus :ConnectStatusType [0..1]+ inverterStatus :InverterStatusType [0..1]+ localControlModeStatus :LocalControlModeStatusType [0..1]+ manufacturerStatus :ManufacturerStatusType [0..1]+ operationalModeStatus :OperationalModeStatusType [0..1]+ readingTime :TimeType+ stateOfChargeStatus :StateOfChargeStatusType [0..1]+ storageModeStatus :StorageModeStatusType [0..1]+ storConnectStatus :ConnectStatusType [0..1]
SubscribableResourceAbstractDev ice
ResourceDERCapability
+ modesSupported :DERControlType+ rtgA :CurrentRMS+ rtgAh :AmpereHour [0..1]+ rtgMaxChargeRate :ActivePower [0..1]+ rtgMaxDischargeRate :ActivePower [0..1]+ rtgMinPF :UnsignedFixedPointType [0..1]+ rtgMinPFNeg :FixedPointType [0..1]+ rtgVA :ApparentPower [0..1]+ rtgVAr :ReactivePower [0..1]+ rtgVArNeg :ReactivePower [0..1]+ rtgW :ActivePower+ rtgWh :WattHour [0..1]+ type :DERType
LinkDERCapabilityLink
SubscribableResourceDERAv ailability
+ availabil ityDuration :UInt32 [0..1]+ maxChargeDuration :UInt32 [0..1]+ readingTime :TimeType+ reserveChargePercent :PerCent [0..1]+ reservePercent :PerCent [0..1]+ statVArAvail :ReactivePower [0..1]+ statWAvail :ActivePower [0..1]
LinkDERAv ailabilityLink
SubscribableResourceDER
ListDERList
LinkDERSettingsLink
ListLinkDERListLink
ListLinkAssociatedDERProgramListLink
LinkAssociatedUsagePointLink
SubscribableResourceDERSettings
+ setGenConnect :boolean [0..1]+ setGradW :UInt16+ setMaxChargeRate :ActivePower [0..1]+ setMaxDischargeRate :ActivePower [0..1]+ setMaxVA :ApparentPower [0..1]+ setMaxVAr :ReactivePower [0..1]+ setMaxVArNeg :ReactivePower [0..1]+ setMaxW :ActivePower+ setMinPF :UnsignedFixedPointType [0..1]+ setMinPFNeg :FixedPointType [0..1]+ setStorConnect :boolean [0..1]+ setVRef :VoltageRMS [0..1]+ setVRefOfs :VoltageRMS [0..1]+ updatedTime :TimeType
LinkCurrentDERProgramLink
0..*
0..1
0..10..10..1
0..10..10..1
0..1
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 231 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
7083
Figure 15-34: DER Info Types 7084
7085
Figure 15-35: DER Program 7086
class DER Info Types
Related DER Info data types
Inv erterStatusType
+ dateTime :TimeType+ value :UInt8
notesDER InverterStatus value:0 - N/A1 - off2 - sleeping (auto-shutdown) or DERis at low output power/voltage3 - starting up or ON but not producing power4 - tracking MPPT power point5 - forced power reduction/derating6 - shutting down7 - one or more faults exist8 - standby (service on unit) - DER may be at high output voltage/power9 - test mode10 - as defined in manufacturer statusAll other values reserved.
LocalControlModeStatusType
+ dateTime :TimeType+ value :UInt8
notesDER LocalControlModeStatus/value:0 – local control1 – remote controlAll other values reserved.
ConnectStatusType
+ dateTime :TimeType+ value :UInt8
notesDER ConnectStatus value:0 - N/A1 - disconnected_unavail2 - disconnected_avail3 - connected_unavail4 - connected_avail5 - connected_on6 - test_modeAll other values reserved.
StorageModeStatusType
+ dateTime :TimeType+ value :UInt8
notesDER StorageModeStatus value:0 – storage charging1 – storage discharging2 – storage holdingAll other values reserved.
OperationalModeStatusType
+ dateTime :TimeType+ value :UInt8
notesDER OperationalModeStatus value:0 - Not applicable / Unknown1 - Off2 - Operational mode3 - Test modeAll other values reserved.
StateOfChargeStatusType
+ dateTime :TimeType+ value :PerCent
notesDER StateOfChargeStatus value: Percent data type
ManufacturerStatusType
+ dateTime :TimeType+ value :String6
notesDER ManufacturerStatus/value: String data type
UInt8DERType
notes0 - Not applicable / Unknown 1 - Virtual or mixed DER 2 - Reciprocating engine 3 - Fuel cell 4 - Photovoltaic system 5 - Combined heat and power 80 - Storage (immobile)81 - Electric vehicle / EVSE82 - Combined PV and storageAll other values reserved.
HexBinary32DERControlType
notesControl modes supported by the DER. Bit positions SHALL be defined as follows:0 - Volt-VAr Mode 1 - Frequency-Watt Mode 2 - Watt-PowerFactor Mode 3 - Volt-Watt Mode 4 - Low Voltage Ride Through Mode 5 - High Voltage Ride Through Mode6-9 - reserved 10 - setGenConnect11 - setStorConnect12 - Fixed W13 - Fixed VAr14 - Fixed PF15 - Charge mode16 - Discharge modeAll other values reserved.
class DER Program
ResourceFunctionSetAssignmentsBase
ListLinkDERProgramListLink
UInt8PrimacyType
notesValues possible for indication of "Primary" provider:
0: In home energy management system1: Contracted premises service provider2: Non-contractual service providerAll other values reserved.
ListDERProgramList
ListLinkActiv eDERControlListLink
ListLinkDERControlListLink
IdentifiedObjectDERProgram
+ primacy :PrimacyType::IdentifiedObject+ description :String32 [0..1]+ mRID :mRIDType+ version :VersionType [0..1] = 0
«XSDattribute»::Resource+ href :anyURI [0..1]
Dev iceCapability
LinkDefaultDERControlLink
ListLinkDERCurv eListLink
0..1
0..*
0..1
0..1
0..1
0..1
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 232 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
7087
Figure 15-36: DER Curves 7088
class DER Curv es
Curv eData
+ excitation :Int8 [0..1]+ xvalue :Int32+ yvalue :Int32
UInt8DERCurv eType
notes0 - Volt-VAr Mode 1 - Frequency-Watt Curve Mode 2 - Watt-PowerFactor Mode 3 - Volt-Watt Mode 4 - Low Voltage Ride Through Mode 5 - High Voltage Ride Through ModeAll other values reserved.
ListLinkDERCurv eListLink
IdentifiedObjectDERCurv e
+ creationTime :TimeType+ curveType :DERCurveType+ rampDecTms :UInt16 [0..1]+ rampIncTms :UInt16 [0..1]+ rampPT1Tms :UInt16 [0..1]+ xMultiplier :PowerOfTenMultiplierType+ yMultiplier :PowerOfTenMultiplierType+ yRefType :DERUnitRefType::IdentifiedObject+ description :String32 [0..1]+ mRID :mRIDType+ version :VersionType [0..1] = 0
«XSDattribute»::Resource+ href :anyURI [0..1]
Int8PowerOfTenMultiplierType
notes-9 = nano=x10^-9-6 = micro=x10^-6-3 = mill i=x10^-30 = none=x1 (default, if not specified)1 = deca=x102 = hecto=x1003 = kilo=x10006 = Mega=x10^69 = Giga=x10^9This is not a complete list. Any integerbetween -9 and 9 SHALL be supported, indicating the power of tenmultiplier for the units.
ListDERCurv eList
UInt8DERUnitRefType
notesSpecifies context for interpreting percent values:0 - N/A1 - %setMaxW2 - %setMaxVAr3 - %statVArAvail4 - %setEffectiveV5 - %setMaxChargeRate6 - %setMaxDischargeRateAll other values reserved.
Curv ePairType
+ lowerLimit :DERCurveLink+ upperLimit :DERCurveLink
notesSpecifies a pair of DERCurves.
IdentifiedObjectDERProgram
+ primacy :PrimacyType
1..10
0..*
0..1
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 233 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
7089
Figure 15-37: DER Control 7090
class DER Control
Ev entStatus
+ currentStatus :UInt8+ dateTime :TimeType+ potentiallySuperseded :boolean+ potentiallySupersededTime :TimeType [0..1]+ reason :String192 [0..1]
ListLinkDERControlListLink
IdentifiedObjectDERProgram
RespondableSubscribableIdentifiedObjectEv ent
+ creationTime :TimeType+ interval :DateTimeInterval
SubscribableListDERControlList
RandomizableEv ent
+ randomizeDuration :OneHourRangeType [0..1] = 0+ randomizeStart :OneHourRangeType [0..1] = 0
DERControl
DERControlBase
+ opModFixedFlow :SignedPerCent [0..1]+ opModFixedPF :FixedPowerFactor [0..1]+ opModFixedVAr :FixedVAr [0..1]+ opModFixedW :PerCent [0..1]+ opModFreqWatt :DERCurveLink [0..1]+ opModHVRT :CurvePairType [0..1]+ opModLVRT :CurvePairType [0..1]+ opModVoltVAr :DERCurveLink [0..1]+ opModVoltWatt :DERCurveLink [0..1]+ opModWattPF :DERCurveLink [0..1]+ rampTms :UInt16 [0..1]
SubscribableIdentifiedObjectDefaultDERControl
Curv ePairType
+ lowerLimit :DERCurveLink+ upperLimit :DERCurveLink
LinkDefaultDERControlLink
0..1
0..1
1
0..*
1
1
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 234 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
7091
Figure 15-38: DER Control Types 7092
DefaultDERControl Object (SubscribableIdentifiedObject) 7093 Contains control mode information to be used if no active DERControl is found. 7094
DER Object (SubscribableResource) 7095 Contains links to DER resources. 7096
DERList Object (List) 7097 A List element to hold DER objects. 7098
DERSettings Object (SubscribableResource) 7099 Distributed energy resource settings 7100
setGenConnect attribute (boolean) [0..1] 7101 Set generator DER as connected (true) or disconnected (false). 7102
setGradW attribute (UInt16) 7103 Set default rate of change (ramp rate) of active power output due to command or internal action, defined 7104 in %setWMax / second. Resolution is in hundredths of a percent/second and may be in the range 1 - 7105 20000. Interpreted as a percentage change in output capability limit per second when used as a default 7106 ramp rate. 7107
setMaxChargeRate attribute (ActivePower) [0..1] 7108
class DER Control Types
Related DER Control data types
VoltageRMS
+ multiplier :PowerOfTenMultiplierType+ value :UInt16
notesAverage electric potential difference between two points.
CurrentRMS
+ multiplier :PowerOfTenMultiplierType+ value :UInt16
notesAverage flow of charge through a conductor.
ApparentPower
+ multiplier :PowerOfTenMultiplierType+ value :UInt16
notesThe apparent power S (in VA) is the product of root mean square (RMS) voltage and RMS current.
Activ ePower
+ multiplier :PowerOfTenMultiplierType+ value :Int16
notesThe active (real) power P (in W) is the product of root-mean-square (RMS) voltage, RMS current, and cos(theta) where theta is the phase angle of current relative to voltage. It is the primary measure of the rate of flow of energy.
Reactiv ePower
+ multiplier :PowerOfTenMultiplierType+ value :Int16
notesThe reactive power Q (in var) is the product of root mean square (RMS) voltage, RMS current, and sin(theta) where theta is the phase angle of current relative to voltage.
FixedPowerFactor
+ displacement :Int16+ multiplier :PowerOfTenMultiplierType
notesSpecifies a setpoint for Displacement Power Factor, the ratio between apparent and active powers at the fundamental frequency (e.g. 60 Hz).
WattHour
+ multiplier :PowerOfTenMultiplierType+ value :UInt16
notesActive (real) energy
AmpereHour
+ multiplier :PowerOfTenMultiplierType+ value :UInt16
notesAvailable electric charge
FixedVAr
+ refType :DERUnitRefType+ value :SignedPerCent
notesSpecifies a signed setpoint for reactive power.
FixedPointType
+ multiplier :PowerOfTenMultiplierType+ value :Int16
notesAbstract type for specifying a fixed-point value without a given unit of measure.
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 235 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Maximum rate of energy transfer received by the storage device, in Watts. Defaults to 7109 rtgMaxChargeRate. 7110
setMaxDischargeRate attribute (ActivePower) [0..1] 7111 Maximum rate of energy transfer delivered by the storage device, in Watts. Defaults to 7112 rtgMaxDischargeRate. 7113
setMaxVA attribute (ApparentPower) [0..1] 7114 Set limit for maximum apparent power capability of the DER (in VA). Defaults to rtgVA. 7115
setMaxVAr attribute (ReactivePower) [0..1] 7116 Set limit for maximum reactive power delivered by the DER (in var). SHALL be a positive value <= 7117 rtgVAr (default). 7118
setMaxVArNeg attribute (ReactivePower) [0..1] 7119 Set limit for maximum reactive power received by the DER (in var). If present, SHALL be a negative 7120 value >= rtgVArNeg (default). If absent, defaults to negative setMaxVAr. 7121
setMaxW attribute (ActivePower) 7122 Set limit for maximum active power capability of the DER (in W). Defaults to rtgW. 7123
setMinPF attribute (UnsignedFixedPointType) [0..1] 7124 Set minimum Power Factor displacement limit of the DER; positive value between 0.0 (typically > 0.7) 7125 and 1.0. SHALL be >= rtgMinPF (default). 7126
setMinPFNeg attribute (FixedPointType) [0..1] 7127 Set minimum Power Factor displacement limit of the DER; negative value between 0.0 (typically < -0.7) 7128 and -0.9999. If present, SHALL be <= rtgMinPFNeg (default). If absent, defaults to negative setMinPF. 7129
setStorConnect attribute (boolean) [0..1] 7130 Set storage DER as connected (true) or disconnected (false). 7131
setVRef attribute (VoltageRMS) [0..1] 7132 The nominal AC voltage (RMS) at the utility's point of common coupling. 7133
setVRefOfs attribute (VoltageRMS) [0..1] 7134 The nominal AC voltage (RMS) offset between the DER's electrical connection point and the utility's 7135 point of common coupling. 7136
updatedTime attribute (TimeType) 7137 Specifies the time at which the DER information was last updated. 7138
DERType Object (UInt8) 7139 0 - Not applicable / Unknown 7140
1 - Virtual or mixed DER 7141
2 - Reciprocating engine 7142
3 - Fuel cell 7143
4 - Photovoltaic system 7144
5 - Combined heat and power 7145
80 - Storage (immobile) 7146
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 236 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
81 - Electric vehicle / EVSE 7147
82 - Combined PV and storage 7148
All other values reserved. 7149
DERAvailability Object (SubscribableResource) 7150 Indicates current reserve generation status 7151
availabilityDuration attribute (UInt32) [0..1] 7152 Indicates number of seconds the DER will be able to deliver active power at the reservePercent level. 7153
maxChargeDuration attribute (UInt32) [0..1] 7154 Indicates number of seconds the DER will be able to receive active power at the reserveChargePercent 7155 level. 7156
readingTime attribute (TimeType) 7157 The timestamp when the DER availability was last updated. 7158
reserveChargePercent attribute (PerCent) [0..1] 7159 Percent of continuous received active power (%setMaxChargeRate) that is estimated to be available in 7160 reserve. 7161
reservePercent attribute (PerCent) [0..1] 7162 Percent of continuous delivered active power (%setMaxW) that is estimated to be available in reserve. 7163
statVArAvail attribute (ReactivePower) [0..1] 7164 Estimated reserve reactive power, in var. Represents the lesser of received or delivered reactive power. 7165
statWAvail attribute (ActivePower) [0..1] 7166 Estimated reserve active power, in watts. 7167
DERCapability Object (Resource) 7168 Distributed energy resource type and nameplate ratings. 7169
modesSupported attribute (DERControlType) 7170 Bitmap indicating the DER Controls implemented by the device. See DERControlType for values. 7171
rtgA attribute (CurrentRMS) 7172 Maximum continuous AC current capability of the DER, in Amperes (RMS). 7173
rtgAh attribute (AmpereHour) [0..1] 7174 Usable energy storage capacity of the DER, in AmpHours. 7175
rtgMaxChargeRate attribute (ActivePower) [0..1] 7176 Maximum rate of energy transfer received by the storage DER, in Watts. 7177
rtgMaxDischargeRate attribute (ActivePower) [0..1] 7178 Maximum rate of energy transfer delivered by the storage DER, in Watts. Required for combined 7179 generation/storage DERs (e.g. DERType == 82). 7180
rtgMinPF attribute (UnsignedFixedPointType) [0..1] 7181 Minimum Power Factor displacement capability of the DER; SHALL be a positive value between 0.0 7182 (typically > 0.7) and 1.0. If absent, defaults to unity. (Unity power factor is considered unsigned.) 7183
rtgMinPFNeg attribute (FixedPointType) [0..1] 7184 Minimum Power Factor displacement capability of the DER; SHALL be a negative value between 0.0 7185
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 237 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
(typically < -0.7) and -0.9999. If absent, defaults to negative rtgMinPF. (Unity power factor is considered 7186 unsigned.) 7187
rtgVA attribute (ApparentPower) [0..1] 7188 Maximum continuous apparent power output capability of the DER, in VA. 7189
rtgVAr attribute (ReactivePower) [0..1] 7190 Maximum continuous reactive power delivered by the DER, in var. 7191
rtgVArNeg attribute (ReactivePower) [0..1] 7192 Maximum continuous reactive power received by the DER, in var. If absent, defaults to negative rtgVAr. 7193
rtgW attribute (ActivePower) 7194 Maximum continuous active power output capability of the DER, in watts. Represents combined 7195 generation plus storage output if DERType == 82. 7196
rtgWh attribute (WattHour) [0..1] 7197 Maximum energy storage capacity of the DER, in WattHours. 7198
type attribute (DERType) 7199 Type of DER; see DERType object 7200
DERControlBase Object () 7201 Distributed Energy Resource (DER) control values. 7202
opModFixedFlow attribute (SignedPerCent) [0..1] 7203 The opModFixedFlow function specifies a requested charge or discharge mode setpoint, 7204 in %setMaxChargeRate if negative value or %setMaxW or %setMaxDischargeRate if positive value (in 7205 hundredths). SHALL be ignored if device is not a storage DER or setStorConnect is false. 7206
opModFixedPF attribute (FixedPowerFactor) [0..1] 7207 The opModFixedPF function specifies a requested fixed Power Factor (PF) setting, consisting of a signed 7208 displacement value. The PF sign (which SHALL be interpreted according to the EEI convention, where 7209 unity PF is considered unsigned) indicates the direction of reactive power flow. The actual displacement 7210 SHALL be within the limits established by setMinPF and setMinPFNeg. If issued simultaneously with 7211 other reactive power controls (e.g. opModFixedVAr) the control resulting in least var magnitude takes 7212 precedence. 7213
opModFixedVAr attribute (FixedVAr) [0..1] 7214 The opModFixedVAr function specifies the delivered or received reactive power limit setpoint. The 7215 context for the limit value is determined by refType and SHALL be one of %setMaxW, %setMaxVAr, 7216 or %statVArAvail. If issued simultaneously with other reactive power controls (e.g. opModFixedPF) the 7217 control resulting in least var magnitude takes precedence. 7218
opModFixedW attribute (PerCent) [0..1] 7219 The opModFixedW function sets the maximum active power generation level at the electrical coupling 7220 point as a percentage of set capacity (%setMaxW, in hundredths). This limitation may be met e.g. by 7221 reducing PV output or by using excess PV output to charge associated storage. 7222
opModFreqWatt attribute (DERCurveLink) [0..1] 7223 Specify DERCurveLink for curve type == 1. The Frequency-Watt function limits active power 7224 generation or consumption when the line frequency deviates from nominal by a specified amount. The 7225 Frequency-Watt curve is specified as an array of Frequency-Watt pairs that are interpolated into a 7226 piecewise linear function with hysteresis. The x value of each pair specifies a frequency in Hz. The y 7227
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 238 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
value specifies a corresponding active power output in %setMaxW * 100 (0 - 10000) (hundredths of a 7228 percent). 7229
opModHVRT attribute (CurvePairType) [0..1] 7230 Specify curve pair for curve type == 5. The High Voltage Ride-Through (HVRT) function is specified by 7231 one or two duration-volt curves that define the operating region under high voltage conditions. Each 7232 HVRT curve is specified by an array of duration-volt pairs that will be interpolated into a piecewise linear 7233 function that defines an operating region. The x value of each pair specifies a duration (time at a given 7234 voltage in seconds). The y value of each pair specifies an effective percent voltage, defined as (100% * 7235 (locally measured voltage - setVRefOfs) / setVRef), in hundredths of a percent. The upperLimit curve 7236 delineates the "must disconnect" region and SHALL be defined for this control to be active. The 7237 (optional) lowerLimit curve delineates the "must remain connected" region. If the "must remain 7238 connected" curve is not specified, it is assumed to be the same as the "must disconnect" curve. 7239
opModLVRT attribute (CurvePairType) [0..1] 7240 Specify curve pair for curve type == 4. The Low Voltage Ride-Through (LVRT) function is specified by 7241 one or two duration-volt curves that define the operating region under low voltage conditions. Each 7242 LVRT curve is specified by an array of duration-volt pairs that will be interpolated into a piecewise linear 7243 function that defines an operating region. The x value of each pair specifies a duration (time at a given 7244 voltage in seconds). The y value of each pair specifies an effective percent voltage, defined as (100% * 7245 (locally measured voltage - setVRefOfs) / setVRef), in hundredths of a percent. The lowerLimit curve 7246 delineates the "must disconnect" region and SHALL be defined for this control to be active. The 7247 (optional) upperLimit curve delineates the "must remain connected" region. If the "must remain 7248 connected" curve is not specified, it is assumed to be the same as the "must disconnect" curve. 7249
opModVoltVAr attribute (DERCurveLink) [0..1] 7250 Specify DERCurveLink for curve type == 0. The static Volt-VAr function provides over- or under-7251 excited VAr compensation as a function of measured voltage. The Volt-VAr curve is specified as an array 7252 of Volt-VAr pairs that are interpolated into a piecewise linear function with hysteresis. The x value of 7253 each pair specifies an effective percent voltage, defined as (100% * (locally measured voltage - 7254 setVRefOfs) / setVRef) and SHOULD support a domain of at least 0 - 13500 (in hundredths of a percent). 7255 The y value specifies a target VAr output interpreted as SignedPerCent (10000 to -10000). The meaning 7256 of the y value is determined by yRefType and must be one of %setMaxW, %setMaxVAr, 7257 or %statVArAvail, all in hundredths of a percent. 7258
opModVoltWatt attribute (DERCurveLink) [0..1] 7259 Specify DERCurveLink for curve type == 3. The Volt-Watt reduces active power output as a function of 7260 measured voltage. The Volt-Watt curve is specified as an array of Volt-Watt pairs that are interpolated 7261 into a piecewise linear function with hysteresis. The x value of each pair specifies an effective percent 7262 voltage, defined as (100% * (locally measured voltage - setVRefOfs) / setVRef) and SHOULD support a 7263 domain of at least 0 - 13500 (in hundredths of a percent). The y value specifies an active power output 7264 in %setMaxW, (0 - 10000) in hundredths of a percent. 7265
opModWattPF attribute (DERCurveLink) [0..1] 7266 Specify DERCurveLink for curve type == 2. The Watt-PF function varies Power Factor (PF) as a 7267 function of delivered active power. The Watt-PF curve is specified as an array of Watt-PF coordinates 7268 that are interpolated into a piecewise linear function with hysteresis. The x value of each pair specifies a 7269 watt setting in %setMaxW, (0 - 10000) in hundredths of a percent. The PF output setting is a signed 7270 displacement in y value (PF sign SHALL be interpreted according to the EEI convention, where unity PF 7271 is considered unsigned). These settings are not expected to be updated very often during the life of the 7272
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 239 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
installation, therefore only a single curve is required. If issued simultaneously with other reactive power 7273 controls (e.g. opModFixedPF) the control resulting in least var magnitude takes precedence. 7274
rampTms attribute (UInt16) [0..1] 7275 Requested ramp time, in hundredths of a second, for the device to transition from the current DERControl 7276 mode setting(s) to the new mode setting(s). If absent, use default ramp rate (setWGrad). Resolution is 7277 1/100 sec. 7278
DERControl Object (RandomizableEvent) 7279 Distributed Energy Resource (DER) time/event-based control. 7280
DERControlList Object (SubscribableList) 7281 A List element to hold DERControl objects. 7282
DERControlType Object (HexBinary32) 7283 Control modes supported by the DER. Bit positions SHALL be defined as follows: 7284
0 - Volt-VAr Mode 7285
1 - Frequency-Watt Mode 7286
2 - Watt-PowerFactor Mode 7287
3 - Volt-Watt Mode 7288
4 - Low Voltage Ride Through Mode 7289
5 - High Voltage Ride Through Mode 7290
6-9 - reserved 7291
10 - setGenConnect 7292
11 - setStorConnect 7293
12 - Fixed W 7294
13 - Fixed VAr 7295
14 - Fixed PF 7296
15 - Charge mode 7297
16 - Discharge mode 7298
All other values reserved. 7299
DERCurve Object (IdentifiedObject) 7300 DER related curves such as Volt-VAr mode curves. Relationship between an independent 7301 variable (X-axis) and one or two dependent variables (Y-axis and excitation). 7302
creationTime attribute (TimeType) 7303 The time at which the object was created. 7304
curveType attribute (DERCurveType) 7305 Specifies the associated curve-based control mode. 7306
rampDecTms attribute (UInt16) [0..1] 7307 Decreasing ramp rate, interpreted as a percentage change in output capability limit per second 7308 (e.g. %setMaxW / sec). Resolution is in hundredths of a percent/second and may be in the range 1 - 7309
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 240 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
20000. If absent, ramp rate defaults to setWGrad. 7310
rampIncTms attribute (UInt16) [0..1] 7311 Increasing ramp rate, interpreted as a percentage change in output capability limit per second 7312 (e.g. %setMaxW / sec). Resolution is in hundredths of a percent/second and may be in the range 1 - 7313 20000. If absent, ramp rate defaults to rampDecTms. 7314
rampPT1Tms attribute (UInt16) [0..1] 7315 The configuration parameter for a low-pass filter, PT1 is a time, in hundredths of a second, in which the 7316 filter will settle to 95% of a step change in the input value. Resolution is 1/100 sec. 7317
xMultiplier attribute (PowerOfTenMultiplierType) 7318 Exponent for X-axis value. 7319
yMultiplier attribute (PowerOfTenMultiplierType) 7320 Exponent for Y-axis value. 7321
yRefType attribute (DERUnitRefType) 7322 The Y-axis units context. 7323
CurrentDERProgramLink Object (Link) 7324 SHALL contain a Link to an instance of DERProgram. If present, this is the DERProgram 7325 containing the currently active DERControl. 7326
DERCurveList Object (List) 7327 A List element to hold DERCurve objects. 7328
CurveData Object () 7329 Data point values for defining a curve or schedule 7330
excitation attribute (Int8) [0..1] 7331 To be included with curve type 2 (Watt-PowerFactor), specifies the excitation of the power factor. 7332
-1 = under-excited 7333
1 = over-excited 7334
xvalue attribute (Int32) 7335 The data value of the X-axis (independent) variable, depending on the curve type. See definitions in 7336 DERControlBase for further information. 7337
yvalue attribute (Int32) 7338 The data value of the Y-axis (dependent) variable, depending on the curve type. See definitions in 7339 DERControlBase for further information. 7340
DERCurveType Object (UInt8) 7341 0 - Volt-VAr Mode 7342
1 - Frequency-Watt Curve Mode 7343
2 - Watt-PowerFactor Mode 7344
3 - Volt-Watt Mode 7345
4 - Low Voltage Ride Through Mode 7346
5 - High Voltage Ride Through Mode 7347
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 241 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
All other values reserved. 7348
CurvePairType Object () 7349 Specifies a pair of DERCurves. 7350
lowerLimit attribute (DERCurveLink) 7351 DERCurveLink for lower bound of operating region. 7352
upperLimit attribute (DERCurveLink) 7353 DERCurveLink for upper bound of operating region. 7354
DERProgram Object (IdentifiedObject) 7355 Distributed Energy Resource program. 7356
primacy attribute (PrimacyType) 7357 Indicates the relative primacy of the provider of this Program. 7358
DERProgramList Object (List) 7359 A List element to hold DERProgram objects. 7360
DERStatus Object (SubscribableResource) 7361 DER status information. 7362
genConnectStatus attribute (ConnectStatusType) [0..1] 7363 Connect/status value for generator DER. 7364
See ConnectStatusType for values. 7365
inverterStatus attribute (InverterStatusType) [0..1] 7366 DER InverterStatus/value. 7367
See InverterStatusType for values. 7368
localControlModeStatus attribute (LocalControlModeStatusType) [0..1] 7369 The local control mode status. 7370
See LocalControlModeStatusType for values. 7371
manufacturerStatus attribute (ManufacturerStatusType) [0..1] 7372 Manufacturer status code. 7373
operationalModeStatus attribute (OperationalModeStatusType) [0..1] 7374 Operational mode currently in use. 7375
See OperationalModeStatusType for values. 7376
readingTime attribute (TimeType) 7377 The timestamp when the current status was last updated. 7378
stateOfChargeStatus attribute (StateOfChargeStatusType) [0..1] 7379 State of charge status. 7380
See StateOfChargeStatusType for values. 7381
storageModeStatus attribute (StorageModeStatusType) [0..1] 7382 Storage mode status. 7383
See StorageModeStatusType for values. 7384
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 242 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
storConnectStatus attribute (ConnectStatusType) [0..1] 7385 Connect/status value for storage DER. 7386
See ConnectStatusType for values. 7387
DERUnitRefType Object (UInt8) 7388 Specifies context for interpreting percent values: 7389
0 - N/A 7390
1 - %setMaxW 7391
2 - %setMaxVAr 7392
3 - %statVArAvail 7393
4 - %setEffectiveV 7394
5 - %setMaxChargeRate 7395
6 - %setMaxDischargeRate 7396
All other values reserved. 7397
CurrentRMS Object () 7398 Average flow of charge through a conductor. 7399
multiplier attribute (PowerOfTenMultiplierType) 7400 Specifies exponent of value. 7401
value attribute (UInt16) 7402 Value in amperes RMS (uom 5) 7403
FixedPointType Object () 7404 Abstract type for specifying a fixed-point value without a given unit of measure. 7405
multiplier attribute (PowerOfTenMultiplierType) 7406 Specifies exponent of uom. 7407
value attribute (Int16) 7408 Dimensionless value 7409
UnsignedFixedPointType Object () 7410 Abstract type for specifying an unsigned fixed-point value without a given unit of measure. 7411
multiplier attribute (PowerOfTenMultiplierType) 7412 Specifies exponent of uom. 7413
value attribute (UInt16) 7414 Dimensionless value 7415
ActivePower Object () 7416 The active (real) power P (in W) is the product of root-mean-square (RMS) voltage, RMS 7417 current, and cos(theta) where theta is the phase angle of current relative to voltage. It is the 7418 primary measure of the rate of flow of energy. 7419
multiplier attribute (PowerOfTenMultiplierType) 7420 Specifies exponent for uom. 7421
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 243 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
value attribute (Int16) 7422 Value in watts (uom 38) 7423
AmpereHour Object () 7424 Available electric charge 7425
multiplier attribute (PowerOfTenMultiplierType) 7426 Specifies exponent of uom. 7427
value attribute (UInt16) 7428 Value in ampere-hours (uom 106) 7429
ApparentPower Object () 7430 The apparent power S (in VA) is the product of root mean square (RMS) voltage and RMS 7431 current. 7432
multiplier attribute (PowerOfTenMultiplierType) 7433 Specifies exponent of uom. 7434
value attribute (UInt16) 7435 Value in volt-amperes (uom 61) 7436
ReactivePower Object () 7437 The reactive power Q (in var) is the product of root mean square (RMS) voltage, RMS current, 7438 and sin(theta) where theta is the phase angle of current relative to voltage. 7439
multiplier attribute (PowerOfTenMultiplierType) 7440 Specifies exponent of uom. 7441
value attribute (Int16) 7442 Value in volt-amperes reactive (var) (uom 63) 7443
FixedPowerFactor Object () 7444 Specifies a setpoint for Displacement Power Factor, the ratio between apparent and active powers 7445 at the fundamental frequency (e.g. 60 Hz). 7446
displacement attribute (Int16) 7447 Significand of a signed value of cos(theta) between -0.9999 and 1.0. E.g. a value of -0.95 may be 7448 specified as a displacement of -950 and a multiplier of -3. Sign SHALL be interpreted according to the 7449 EEI convention. 7450
multiplier attribute (PowerOfTenMultiplierType) 7451 Specifies exponent of 'displacement'. 7452
FixedVAr Object () 7453 Specifies a signed setpoint for reactive power. 7454
refType attribute (DERUnitRefType) 7455 Indicates whether to interpret 'value' as %setMaxVAr or %statVArAvail. 7456
value attribute (SignedPerCent) 7457 Specify a signed setpoint for reactive power in % (see 'refType' for context). 7458
WattHour Object () 7459 Active (real) energy 7460
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 244 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
multiplier attribute (PowerOfTenMultiplierType) 7461 Specifies exponent of uom. 7462
value attribute (UInt16) 7463 Value in watt-hours (uom 72) 7464
VoltageRMS Object () 7465 Average electric potential difference between two points. 7466
multiplier attribute (PowerOfTenMultiplierType) 7467 Specifies exponent of uom. 7468
value attribute (UInt16) 7469 Value in volts RMS (uom 29) 7470
ConnectStatusType Object () 7471 DER ConnectStatus value: 7472
0 - N/A 7473
1 - disconnected_unavail 7474
2 - disconnected_avail 7475
3 - connected_unavail 7476
4 - connected_avail 7477
5 - connected_on 7478
6 - test_mode 7479
All other values reserved. 7480
dateTime attribute (TimeType) 7481 The date and time at which the state applied. 7482
value attribute (UInt8) 7483 The value indicating the state. 7484
InverterStatusType Object () 7485 DER InverterStatus value: 7486
0 - N/A 7487
1 - off 7488
2 - sleeping (auto-shutdown) or DER is at low output power/voltage 7489
3 - starting up or ON but not producing power 7490
4 - tracking MPPT power point 7491
5 - forced power reduction/derating 7492
6 - shutting down 7493
7 - one or more faults exist 7494
8 - standby (service on unit) - DER may be at high output voltage/power 7495
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 245 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
9 - test mode 7496
10 - as defined in manufacturer status 7497
All other values reserved. 7498
dateTime attribute (TimeType) 7499 The date and time at which the state applied. 7500
value attribute (UInt8) 7501 The value indicating the state. 7502
LocalControlModeStatusType Object () 7503 DER LocalControlModeStatus/value: 7504
0 – local control 7505
1 – remote control 7506
All other values reserved. 7507
dateTime attribute (TimeType) 7508 The date and time at which the state applied. 7509
value attribute (UInt8) 7510 The value indicating the state. 7511
ManufacturerStatusType Object () 7512 DER ManufacturerStatus/value: String data type 7513
dateTime attribute (TimeType) 7514 The date and time at which the state applied. 7515
value attribute (String6) 7516 The value indicating the state. 7517
OperationalModeStatusType Object () 7518 DER OperationalModeStatus value: 7519
0 - Not applicable / Unknown 7520
1 - Off 7521
2 - Operational mode 7522
3 - Test mode 7523
All other values reserved. 7524
dateTime attribute (TimeType) 7525 The date and time at which the state applied. 7526
value attribute (UInt8) 7527 The value indicating the state. 7528
StateOfChargeStatusType Object () 7529 DER StateOfChargeStatus value: Percent data type 7530
dateTime attribute (TimeType) 7531 The date and time at which the state applied. 7532
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 246 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
value attribute (PerCent) 7533 The value indicating the state. 7534
StorageModeStatusType Object () 7535 DER StorageModeStatus value: 7536
0 – storage charging 7537
1 – storage discharging 7538
2 – storage holding 7539
All other values reserved. 7540
dateTime attribute (TimeType) 7541 The date and time at which the state applied. 7542
value attribute (UInt8) 7543 The value indicating the state. 7544
15.1.22 Links Package 7545
Contains definitions of Link specializations used to require certain associations. 7546
AccountBalanceLink Object (Link) 7547 SHALL contain a Link to an instance of AccountBalance. 7548
ActiveBillingPeriodListLink Object (ListLink) 7549 SHALL contain a Link to a List of active BillingPeriod instances. 7550
ActiveCreditRegisterListLink Object (ListLink) 7551 SHALL contain a Link to a List of active CreditRegister instances. 7552
ActiveDERControlListLink Object (ListLink) 7553 SHALL contain a Link to a List of active DERControl instances. 7554
ActiveEndDeviceControlListLink Object (ListLink) 7555 SHALL contain a Link to a List of active EndDeviceControl instances. 7556
ActiveFlowReservationListLink Object (ListLink) 7557 SHALL contain a Link to a List of active FlowReservation instances. 7558
ActiveProjectionReadingListLink Object (ListLink) 7559 SHALL contain a Link to a List of active ProjectionReading instances. 7560
ActiveSupplyInterruptionOverrideListLink Object (ListLink) 7561 SHALL contain a Link to a List of active SupplyInterruptionOverride instances. 7562
ActiveTargetReadingListLink Object (ListLink) 7563 SHALL contain a Link to a List of active TargetReading instances. 7564
ActiveTextMessageListLink Object (ListLink) 7565 SHALL contain a Link to a List of active TextMessage instances. 7566
ActiveTimeTariffIntervalListLink Object (ListLink) 7567 SHALL contain a Link to a List of active TimeTariffInterval instances. 7568
AssociatedDERProgramListLink Object (ListLink) 7569 SHALL contain a Link to a List of DERPrograms having the DERControl(s) for this DER. 7570
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 247 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
AssociatedUsagePointLink Object (Link) 7571 SHALL contain a Link to an instance of UsagePoint. If present, this is the submeter that 7572 monitors the DER output. 7573
BillingPeriodListLink Object (ListLink) 7574 SHALL contain a Link to a List of BillingPeriod instances. 7575
BillingReadingListLink Object (ListLink) 7576 SHALL contain a Link to a List of BillingReading instances. 7577
BillingReadingSetListLink Object (ListLink) 7578 SHALL contain a Link to a List of BillingReadingSet instances. 7579
ConfigurationLink Object (Link) 7580 SHALL contain a Link to an instance of Configuration. 7581
ConsumptionTariffIntervalListLink Object (ListLink) 7582 SHALL contain a Link to a List of ConsumptionTariffInterval instances. 7583
CreditRegisterListLink Object (ListLink) 7584 SHALL contain a Link to a List of CreditRegister instances. 7585
CustomerAccountLink Object (Link) 7586 SHALL contain a Link to an instance of CustomerAccount. 7587
CustomerAccountListLink Object (ListLink) 7588 SHALL contain a Link to a List of CustomerAccount instances. 7589
CustomerAgreementListLink Object (ListLink) 7590 SHALL contain a Link to a List of CustomerAgreement instances. 7591
DemandResponseProgramLink Object (Link) 7592 SHALL contain a Link to an instance of DemandResponseProgram. 7593
DemandResponseProgramListLink Object (ListLink) 7594 SHALL contain a Link to a List of DemandResponseProgram instances. 7595
DERAvailabilityLink Object (Link) 7596 SHALL contain a Link to an instance of DERAvailability. 7597
DERCapabilityLink Object (Link) 7598 SHALL contain a Link to an instance of DERCapability. 7599
DefaultDERControlLink Object (Link) 7600 SHALL contain a Link to an instance of DefaultDERControl. This is the default mode of the 7601 DER which MAY be overridden by DERControl events. 7602
DERControlListLink Object (ListLink) 7603 SHALL contain a Link to a List of DERControl instances. 7604
DERCurveLink Object (Link) 7605 SHALL contain a Link to an instance of DERCurve. 7606
DERCurveListLink Object (ListLink) 7607 SHALL contain a Link to a List of DERCurve instances. 7608
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 248 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
DERLink Object (Link) 7609 SHALL contain a Link to an instance of DER. 7610
DERListLink Object (ListLink) 7611 SHALL contain a Link to a List of DER instances. 7612
DERProgramLink Object (Link) 7613 SHALL contain a Link to an instance of DERProgram. 7614
DERProgramListLink Object (ListLink) 7615 SHALL contain a Link to a List of DERProgram instances. 7616
DERSettingsLink Object (Link) 7617 SHALL contain a Link to an instance of DERSettings. 7618
DERStatusLink Object (Link) 7619 SHALL contain a Link to an instance of DERStatus. 7620
DeviceCapabilityLink Object (Link) 7621 SHALL contain a Link to an instance of DeviceCapability. 7622
DeviceInformationLink Object (Link) 7623 SHALL contain a Link to an instance of DeviceInformation. 7624
DeviceStatusLink Object (Link) 7625 SHALL contain a Link to an instance of DeviceStatus. 7626
EndDeviceControlListLink Object (ListLink) 7627 SHALL contain a Link to a List of EndDeviceControl instances. 7628
EndDeviceLink Object (Link) 7629 SHALL contain a Link to an instance of EndDevice. 7630
EndDeviceListLink Object (ListLink) 7631 SHALL contain a Link to a List of EndDevice instances. 7632
FileLink Object (Link) 7633 This element MUST be set to the URI of the most recent File being loaded/activated by the LD. 7634 In the case of file status 0, this element MUST be omitted. 7635
FileListLink Object (ListLink) 7636 SHALL contain a Link to a List of File instances. 7637
FileStatusLink Object (Link) 7638 SHALL contain a Link to an instance of FileStatus. 7639
FlowReservationRequestListLink Object (ListLink) 7640 SHALL contain a Link to a List of FlowReservationRequest instances. 7641
FlowReservationResponseListLink Object (ListLink) 7642 SHALL contain a Link to a List of FlowReservationResponse instances. 7643
FunctionSetAssignmentsListLink Object (ListLink) 7644 SHALL contain a Link to a List of FunctionSetAssignments instances. 7645
HistoricalReadingListLink Object (ListLink) 7646 SHALL contain a Link to a List of HistoricalReading instances. 7647
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 249 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
IPAddrListLink Object (ListLink) 7648 SHALL contain a Link to a List of IPAddr instances. 7649
IPInterfaceListLink Object (ListLink) 7650 SHALL contain a Link to a List of IPInterface instances. 7651
LLInterfaceListLink Object (ListLink) 7652 SHALL contain a Link to a List of LLInterface instances. 7653
LoadShedAvailabilityLink Object (Link) 7654 SHALL contain a Link to an instance of LoadShedAvailability. 7655
LogEventListLink Object (ListLink) 7656 SHALL contain a Link to a List of LogEvent instances. 7657
MessagingProgramListLink Object (ListLink) 7658 SHALL contain a Link to a List of MessagingProgram instances. 7659
MeterReadingLink Object (Link) 7660 SHALL contain a Link to an instance of MeterReading. 7661
MeterReadingListLink Object (ListLink) 7662 SHALL contain a Link to a List of MeterReading instances. 7663
MirrorUsagePointListLink Object (ListLink) 7664 SHALL contain a Link to a List of MirrorUsagePoint instances. 7665
NeighborListLink Object (ListLink) 7666 SHALL contain a Link to a List of Neighbor instances. 7667
NotificationListLink Object (ListLink) 7668 SHALL contain a Link to a List of Notification instances. 7669
PowerStatusLink Object (Link) 7670 SHALL contain a Link to an instance of PowerStatus. 7671
PrepaymentLink Object (Link) 7672 SHALL contain a Link to an instance of Prepayment. 7673
PrepaymentListLink Object (ListLink) 7674 SHALL contain a Link to a List of Prepayment instances. 7675
PrepayOperationStatusLink Object (Link) 7676 SHALL contain a Link to an instance of PrepayOperationStatus. 7677
PriceResponseCfgListLink Object (ListLink) 7678 SHALL contain a Link to a List of PriceResponseCfg instances. 7679
ProjectionReadingListLink Object (ListLink) 7680 SHALL contain a Link to a List of ProjectionReading instances. 7681
RateComponentLink Object (Link) 7682 SHALL contain a Link to an instance of RateComponent. 7683
RateComponentListLink Object (ListLink) 7684 SHALL contain a Link to a List of RateComponent instances. 7685
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 250 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
ReadingLink Object (Link) 7686 A Link to a Reading. 7687
ReadingListLink Object (ListLink) 7688 SHALL contain a Link to a List of Reading instances. 7689
ReadingSetListLink Object (ListLink) 7690 SHALL contain a Link to a List of ReadingSet instances. 7691
ReadingTypeLink Object (Link) 7692 SHALL contain a Link to an instance of ReadingType. 7693
RegistrationLink Object (Link) 7694 SHALL contain a Link to an instance of Registration. 7695
ResponseListLink Object (ListLink) 7696 SHALL contain a Link to a List of Response instances. 7697
ResponseSetListLink Object (ListLink) 7698 SHALL contain a Link to a List of ResponseSet instances. 7699
RPLInstanceListLink Object (ListLink) 7700 SHALL contain a Link to a List of RPLInterface instances. 7701
RPLSourceRoutesListLink Object (ListLink) 7702 SHALL contain a Link to a List of RPLSourceRoutes instances. 7703
SelfDeviceLink Object (Link) 7704 SHALL contain a Link to an instance of SelfDevice. 7705
ServiceSupplierLink Object (Link) 7706 SHALL contain a Link to an instance of ServiceSupplier. 7707
SubscriptionListLink Object (ListLink) 7708 SHALL contain a Link to a List of Subscription instances. 7709
SupplyInterruptionOverrideListLink Object (ListLink) 7710 SHALL contain a Link to a List of SupplyInterruptionOverride instances. 7711
SupportedLocaleListLink Object (ListLink) 7712 SHALL contain a Link to a List of SupportedLocale instances. 7713
TargetReadingListLink Object (ListLink) 7714 SHALL contain a Link to a List of TargetReading instances. 7715
TariffProfileLink Object (Link) 7716 SHALL contain a Link to an instance of TariffProfile. 7717
TariffProfileListLink Object (ListLink) 7718 SHALL contain a Link to a List of TariffProfile instances. 7719
TextMessageListLink Object (ListLink) 7720 SHALL contain a Link to a List of TextMessage instances. 7721
TimeLink Object (Link) 7722 SHALL contain a Link to an instance of Time. 7723
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 251 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
TimeTariffIntervalListLink Object (ListLink) 7724 SHALL contain a Link to a List of TimeTariffInterval instances. 7725
UsagePointLink Object (Link) 7726 SHALL contain a Link to an instance of UsagePoint. 7727
UsagePointListLink Object (ListLink) 7728 SHALL contain a Link to a List of UsagePoint instances. 7729
7730
7731
7732
7733
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 252 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
16 Appendix C – Examples and Guidelines [INFORMATIVE] 7734
The contents of this section are not considered to be normative and are provided for reference. Text 7735 contained in { } in the following examples are considered to be placeholders for the actual text or value. 7736
16.1 Registration: Remote 7737
This flow diagram describes client device remote registration to the customer HAN. Note that these are 7738 application layer details only, agnostic to the various layer 2 network joining techniques used by various 7739 PHY/MAC. 7740
7741
Figure 16-1: Remote Registration 7742
Note: An XML example in POX encoding is provided along with the EXI equivalent. 7743
Table 16-1 POX Example: Registration Remote. 7744
Step Description 1 (Out of band) Service provider populates client device's EndDevice (containing SFDI) and
Registration (containing PIN) resources to appropriate HAN registration server (typically the ESI).
2 Client device joins the HAN (layer 2).
3 Client issues DNS-SD request to locate its EndDevice (keyed by its SFDI).
4 A Server or multiple servers provides DNS-SD responses with URL to client's EndDevice. If no reply is found then there are no specific registrations for this device on this network.
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 253 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description 5 For each reply received the client performs TLS and client authentication and executes the
following steps. Note that client certificate is sent in the clear and thus SFDI can be determined.
6 Client and server now have an encrypted connection. Each has determined it is talking to an authenticated SEP 2 device, but have not confirmed they are talking to the correct specific SEP 2 device.
7 Server verifies client identity because client certificate hashes to the client SFDI.
8 Client GETs its EndDevice from Server as returned in DNS-SD Discovery
Client sends the following request: GET /edev/3 HTTP/1.1 Host: {hostname} Accept: application/sep+xml
9 Server responds with the EndDevice resource.
Server sends the following response: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <EndDevice href="/edev/3" subscribable="0" xmlns="http://zigbee.org/sep"> <ConfigurationLink href="/edev/3/cfg"/> <DeviceInformationLink href="/edev/3/di"/> <DeviceStatusLink href="/edev/3/ds"/> <FileStatusLink href="/edev/3/fs"/> <PowerStatusLink href="/edev/3/ps"/> <sFDI>987654321005</sFDI> <FunctionSetAssignmentsListLink all="3" href="/edev/3/fsal"/> <RegistrationLink href="/edev/3/reg"/> <SubscriptionListLink all="0" href="/edev/3/subl"/> </EndDevice>
10 Client GETs its Registration (containing its PIN) from the Server as found in the EndDevice Resource.
Client sends the following request: GET /edev/3/reg HTTP/1.1 Host: {hostname} Accept: application/sep+xml
11 Server responds with the Registration resource. Note: the PIN is thus transmitted over a secure channel.
Server sends the following response: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <Registration href="/edev/3/reg" xmlns="http://zigbee.org/sep"> <pIN>123455</pIN> </Registration>
12 Client verifies its PIN versus that provided by the Server. If the PIN is found to be invalid then the client knows it is not registered with this server.
7745
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 254 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Table 16-2 EXI Example: Registration Remote. 7746
Step Description 1 (same as POX example)
2 (same as POX example)
3 (same as POX example)
4 A Server or multiple servers provides DNS-SD responses with URL to client's EndDevice. If no reply is found then there are no specific registrations for this device on this network. TXT Record: level=+S0
Note: level=+S0 indicates the server can send/receive EXI with SEP 2.0 schema with arbitrary extensions, so subsequent HTTP content on the server may contain extended parts (not used in SEP 2.0 but may be defined in future SEP 2.0.x or SEP 2.x).
5 (same as POX example)
6 (same as POX example)
7 Client GETs its EndDevice from Server as returned in DNS-SD Discovery.
Client sends the following request: GET /edev/3 HTTP/1.1 Host: {hostname} Accept: application/sep-exi; level=-S0
Note: level=-S0 indicates the client can receive EXI with SEP 2.0 schema without any arbitrary elements and attributes.
8 Server responds with the EndDevice resource.
Server sends the following response: HTTP/1.1 200 OK Content-Type: application/sep-exi Content-Length: {contentLength} a030 114c c26a 0049 7b2b 232b b179 9800 0034 bd95 9195 d8bc ccbd 8d99 9c80 c2f6 5646 5762 f332 f646 9003 0bd9 5919 5d8b cccb d91c c018 5eca c8ca ec5e 665e cce6 80c2 f656 4657 62f3 32f7 0731 4995 07ef de04 4030 717b 2b23 2bb1 7999 7b33 9b0b 6006 97b2 b232 bb17 9997 b932 b380 0038 bd95 9195 d8bc ccbd cdd5 89b0
(124-bytes in binary, shown in hexadecimal)
9 Client GETs its Registration (containing its PIN) from the Server as found in the EndDevice Resource.
Client sends the following request: GET /edev/3/reg HTTP/1.1 Host: {hostname} Accept: application/sep-exi; level=-S0
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 255 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description 10 Server responds with the Registration resource. Note: the PIN is thus transmitted over a secure
channel.
Server sends the following response: HTTP/1.1 200 OK Content-Type: application/sep-exi Content-Length: {contentLength} a030 114c c2ef 034b d959 195d 8bcc cbdc 9959 cb96 00
(21-bytes in binary, shown in hexadecimal)
11 (same as POX example)
16.2 Registration: Local 7747
This flow diagram describes client device local registration to the customer HAN. Note that these are 7748 application layer details only, agnostic to the various layer 2 network joining techniques used by various 7749 PHY/MAC. 7750
7751
Figure 16-2: Registration Local 7752
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 256 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Table 16-3 POX Example: Registration Local. 7753
Step Description 1 Client device joins the HAN (layer 2).
2 Client issues DNS-SD request to locate its EndDevice (keyed by its SFDI).
3 Client does not find a desired SFDI response.
4 Client issues DNS-SD request to locate any 'smartenergy' server.
5 A Server or multiple servers provides DNS-SD responses. If no reply is found then no 'smartenergy' servers are present on the network.
6 For each reply received the client performs TLS and client authentication and executes the following steps. Note that client certificate is sent in the clear and thus SFDI can be determined.
Client and server now have an encrypted connection. Each has determined it is talking to an authenticated SEP 2 device, but have not confirmed they are talking to the correct specific SEP 2 device.
7 Client GETs the EndDeviceList from Server as returned in DNS-SD Discovery.
Client sends the following request: GET /edev HTTP/1.1 Host: {hostname} Accept: application/sep+xml
8 Server responds with the EndDeviceList resource.
Server sends the following response: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <EndDeviceList all="1" href="/edev" results="1" subscribable="0" xmlns="http://zigbee.org/sep"> <EndDevice href="/edev/3" subscribable="0"> <ConfigurationLink href="/edev/3/cfg"/> <DeviceInformationLink href="/edev/3/di"/> <DeviceStatusLink href="/edev/3/ds"/> <FileStatusLink href="/edev/3/fs"/> <PowerStatusLink href="/edev/3/ps"/> <sFDI>987654321005</sFDI> <FunctionSetAssignmentsListLink all="3" href="/edev/3/fsal"/> <RegistrationLink href="/edev/3/reg"/> <SubscriptionListLink all="0" href="/edev/3/subl"/> </EndDevice> </EndDeviceList>
9 Client does not find its SFDI in any of the EndDevices in the EndDeviceList.
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 257 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description 10 Client does a POST to EndDeviceList to add its EndDevice to the server.
Client sends the following request: POST /edev HTTP/1.1 Host: {hostname} Content-Type: application/sep+xml Content-Length: {contentLength} <EndDevice href="/edev/3" xmlns="http://zigbee.org/sep"> <sFDI>987654321005</sFDI> </EndDevice>
11 Server indicates the EndDevice Record was created with the following:
If new EndDevice entry is created, the Server would respond with the following where Location indicates the path to the newly created EndDevice resource: HTTP/1.1 201 Created Location: /edev/4
12 Server verifies client identity because client certificate hashes to the client SFDI.
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 258 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
16.3 Discovery: Function Set Assignment 7754
7755
Figure 16-3: Discovery: Function Set Assignment 7756
Note: The Client finds a Server with a validated EndDevice record. The EndDevice Record is found to 7757 have a FunctionSetAssignmentListLink with a FunctionSetAssignment record that contains the desired 7758 Resource. 7759
Table 16-4 POX Example: Discovery Function Set Assignment 7760
Step Description 1 (See Registration Examples)
2 (See Registration Examples)
3 (See Registration Examples)
4 (See Registration Examples)
5 (See Registration Examples)
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 259 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description 6 Server responds with the EndDevice resource with a FunctionSetAssignmentListLink.
Server sends the following response: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <EndDevice href="/edev/3" subscribable="0" xmlns="http://zigbee.org/sep"> <ConfigurationLink href="/edev/3/cfg"/> <DeviceInformationLink href="/edev/3/di"/> <DeviceStatusLink href="/edev/3/ds"/> <FileStatusLink href="/edev/3/fs"/> <PowerStatusLink href="/edev/3/ps"/> <sFDI>987654321005</sFDI> <FunctionSetAssignmentsListLink all="2" href="/edev/3/fsal"/> <RegistrationLink href="/edev/3/reg"/> <SubscriptionListLink all="0" href="/edev/3/subl"/> </EndDevice>
7 (See Registration Examples)
8 (See Registration Examples)
9 (See Registration Examples)
10 Client GETs its FunctionSetAssignment from the Server as found in the EndDevice Resource.
Client sends the following request: GET /edev/3/fsal?l=2 HTTP/1.1 Host: {hostname} Accept: application/sep+xml
11 Server responds with the FunctionSetAssignment resource.
Server sends the following response: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <FunctionSetAssignmentsList all="2" href="/edev/3/fsal" results="2" subscribable="0" xmlns="http://zigbee.org/sep"> <FunctionSetAssignments href="/edev/3/fsal/0" subscribable="0"> <DemandResponseProgramListLink all="2" href="/edev/3/fsa1/0/drpl"/> <MessagingProgramListLink all="1" href="/edev/3/fsa1/0/msgl"/> <mRID>0ED30F5A0000</mRID> <description>FunctionSetAssignment Suave</description> </FunctionSetAssignments> <FunctionSetAssignments href="/edev/3/fsal/1" subscribable="0"> <MessagingProgramListLink all="1" href="/edev/3/fsa1/1/msgl"/> <mRID>0ED30F5A0001</mRID> <description>FunctionSetAssignment Guttural</description> </FunctionSetAssignments> </FunctionSetAssignmentsList>
12 Client GETs its desired Resource from the Server as found in the FunctionSetAssignment Resource. In this case, the Resource of choice is a DemandResponseProgram.
(see DemandResponse Examples)
13 (see DemandResponse Examples)
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 260 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
16.4 Discovery: Without Function Set Assignment 7761
7762
Figure 16-4: Discovery Without Function Set Assignment 7763
Note: The Client finds a Server with a validated EndDevice record. The EndDevice Record is not found to 7764 have a FunctionSetAssignmentListLink with a FunctionSetAssignment record that contains the desired 7765 Resource. 7766
Table 16-5 POX Example: Discovery Without Function Set Assignment. 7767
Step Description 1 (See Registration Examples)
2 (See Registration Examples)
3 (See Registration Examples)
4 (See Registration Examples)
5 (See Registration Examples)
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 261 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description 6 Server responds with the EndDevice resource without a FunctionSetAssignmentListLink. In this
case, the Resource of choice is a DemandResponseProgram which is not a direct member of EndDevice.
Server sends the following response: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <EndDevice href="/edev/3" subscribable="0" xmlns="http://zigbee.org/sep"> <ConfigurationLink href="/edev/3/cfg"/> <DeviceInformationLink href="/edev/3/di"/> <DeviceStatusLink href="/edev/3/ds"/> <FileStatusLink href="/edev/3/fs"/> <PowerStatusLink href="/edev/3/ps"/> <sFDI>987654321005</sFDI> <RegistrationLink href="/edev/3/reg"/> <SubscriptionListLink all="0" href="/edev/3/subl"/> </EndDevice>
7 (See Registration Examples)
8 (See Registration Examples)
9 (See Registration Examples)
10 Client GETs its DeviceCapabilities from the Server as found in the DNS-SD TXT Record.
Client sends the following request: GET /dcap HTTP/1.1 Host: {hostname} Accept: application/sep+xml
11 Server responds with the DeviceCapabilities resource.
Server sends the following response: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <DeviceCapability href="/dcap" xmlns="http://zigbee.org/sep"> <DemandResponseProgramListLink all="1" href="/drp"/> <MessagingProgramListLink all="2" href="/msg"/> <EndDeviceListLink all="1" href="/edev"/> <SelfDeviceLink href="/sdev"/> </DeviceCapability>
12 Client GETs its desired Resource from the Server as found in the DeviceCapabilities Resource. In this case, the Resource of choice is a DemandResponseProgram.
(see DemandResponse Examples)
13 (see DemandResponse Examples)
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 262 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
16.5 Discovery: Undirected Without Function Set Assignment 7768
7769
Figure 16-5: Discovery Undirected Without Function Set Assignment 7770
Note: The Client discovers all Servers and searches through the records to find a Server with a validated 7771 EndDevice record for itself. The EndDevice Record is not found to have a FunctionSetAssignmentListLink 7772 with a FunctionSetAssignment record that contains the desired Resource. The Client searches for the 7773 desired Resource in EndDevice or in DeviceCapabilities. 7774
Table 16-6 POX Example: Discovery Undirected Without Function Set Assignment. 7775
Step Description 1 (See Registration: Local Example)
2 (See Registration: Local Example)
3 (See Registration: Local Example)
4 (See Registration: Local Example)
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 263 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description 5 (See Resource Discovery: Without Function Set Assignment Example)
6 (See Resource Discovery: Without Function Set Assignment Example)
7 (See Registration: Local Example)
8 (See Registration: Local Example)
9 The Client searches through the List of EndDevice Records to find one with a matching SFDI. If not found, the Server contains no records for the Client.
10 (See Registration: Remote Example)
11 (See Registration: Remote Example)
12 (See Registration: Remote Example)
13 (See Resource Discovery: Without Function Set Assignment Example)
14 (See Resource Discovery: Without Function Set Assignment Example)
16.6 Subscription / Notification 7776
7777
Figure 16-6: Subscription / Notification 7778
Note: An XML example in POX encoding is provided along with the EXI equivalent. 7779
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 264 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Table 16-7 POX Example: Subscription / Notification. 7780
Step Description 1 After discovering the URI of the server's SubscriptionList and desired Resource, the Client can
append new subscription entries to the list.
Note: In this case, the Client is conditionally subscribing to an instantaneous meter reading value. If the value is less than 10 or greater than 1000, a notification is sent to the specified notificationURI in the POX encoded format. POST /edev/8/sub HTTP/1.1 Host: {hostname} Content-Type: application/sep+xml Content-Length: {contentLength} <Subscription xmlns="http://zigbee.org/sep"> <subscribedResource>/upt/0/mr/4/r</subscribedResource> <Condition> <attributeIdentifier>0</attributeIdentifier> <lowerThreshold>10</lowerThreshold> <upperThreshold>1000</upperThreshold> </Condition> <encoding>0</encoding> <level>+S0</level> <limit>1</limit> <notificationURI>/note</notificationURI> </Subscription>
2 If new subscription entries are created, the Server would respond with the following, where Location indicates the path to the newly created Subscription resource: HTTP/1.1 201 Created Location: /edev/8/sub/5
If entries were not created but modified the Server would respond with: HTTP/1.1 204 No Content
3 A change on the subscribed resource occurs which satisfies the above specified Conditions.
4 Notification is sent from the Server to the Client: POST /note HTTP/1.1 Host: {hostname} Content-Type: application/sep+xml Content-Length: {contentLength} <Notification xmlns="http://zigbee.org/sep"> <subscribedResource>/upt/0/mr/4/r</subscribedResource> <Resource xsi:type="Reading"> <timePeriod> <duration>0</duration> <start>12987364</start> </timePeriod> <value>1001</value> </Resource> <status>0</status> <subscriptionURI>/edev/8/sub/5</subscriptionURI> </Notification>
5 The Client responds with HTTP Response: HTTP/1.1 201 Created
7781
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 265 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Table 16-8 EXI Example: Subscription / Notification. 7782
Step Description 1 (same as POX example with the following exceptions)
POST format is set with
Content-Type: application/sep-exi
Notification encoding type is specified with:
<encoding>1</encoding>
Notification schema version and options are specified with
<level>-S0</level> POST /edev/8/sub HTTP/1.1 Host: {hostname} Content-Type: application/sep-exi Content-Length: {contentLength} a030 114c c30c 41e5 eeae 0e85 e605 edae 45e6 85ee 4000 00a0 e807 0010 0a5a a660 0040 397b 737b a328
(40-bytes in binary, shown in hexadecimal)
2 (same as POX example)
3 (same as POX example)
4 (same as POX example with the following exceptions)
POST format is set with
Content-Type: application/sep-exi POST /note HTTP/1.1 Host: {hostname} Content-Type: application/sep-exi Content-Length: {contentLength} a030 114c c2b5 41e5 eeae 0e85 e605 edae 45e6 85ee 4614 0100 63a4 1c80 003c bd95 9195 d8bc e0bd cdd5 88bc d4
(43-bytes in binary, shown in hexadecimal)
5 (same as POX example)
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 266 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
16.7 Demand Response: General 7783
7784
Figure 16-7: Demand Response General 7785
Table 16-9 POX Example: Demand Response – General. 7786
Step Description 1 The client has discovered its EndDevice instance on the Server with a link to its
FunctionSetAssignments. Within its FunctionSetAssignments, the client discovers it is part of a DemandResponseProgram. The enrollment is provided out of band.
2 Client GETs the list of DemandResponsePrograms from the DRLC Server.
Client sends the following request: GET /drp?l=2 HTTP/1.1 Host: {hostname} Accept: application/sep+xml
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 267 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description 3 DemandResponse server responds with the list of DemandResponsePrograms.
Server sends the following response: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <DemandResponseProgramList all="2" results="2" subscribable="0" xmlns="http://zigbee.org/sep"> <DemandResponseProgram href="/drp/1"> <mRID>0FB7</mRID> <description>Operation X</description> <ActiveEndDeviceControlListLink all="0" href="/drp/1/aedc"/> <EndDeviceControlListLink all="1" href="/drp/1/edc"/> <primacy>0</primacy> </DemandResponseProgram> <DemandResponseProgram href="/drp/2"> <mRID>80000001</mRID> <description>The Wackness</description> <ActiveEndDeviceControlListLink all="0" href="/drp/2/aedc"/> <EndDeviceControlListLink all="0" href="/drp/2/edc"/> <primacy>1</primacy> </DemandResponseProgram> </DemandResponseProgramList>
4 Client GETs the list of EndDeviceControls from the DRLC Server for the desired DemandResponseProgram.
Client sends the following request: GET /drp/1/edc HTTP/1.1 Host: {hostname} Accept: application/sep+xml
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 268 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description 5 DemandResponse server responds with the list of EndDeviceControls.
Server sends the following response: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <EndDeviceControlList all="1" results="1" subscribable="0" xmlns="http://zigbee.org/sep"> <EndDeviceControl href="/drp/1/edc" replyTo="{hostname}/rsp" responseRequired="01" subscribable="0"> <mRID>CAFEFEED</mRID> <description>Emergency One Hour Coffee Brew</description> <creationTime>1234556</creationTime> <EventStatus> <currentStatus>0</currentStatus> <dateTime>1234556</dateTime> <potentiallySuperseded>false</potentiallySuperseded> <reason>Need Caffeine Soon</reason> </EventStatus> <interval> <duration>360</duration> <start>1234900</start> </interval> <randomizeDuration>60</randomizeDuration> <randomizeStart>60</randomizeStart> <deviceCategory>08</deviceCategory> <drProgramMandatory>true</drProgramMandatory> <loadShiftForward>true</loadShiftForward> <SetPoint> <heatingSetpoint>10000</heatingSetpoint> </SetPoint> </EndDeviceControl> </EndDeviceControlList>
6 For each EndDeviceControl with ResponseRequired Bit 0, set the Client POSTs a Response with a Status of "Event Received" to the Response resource specified by the replyTo field in the EndDeviceControl.
Client sends the following: POST /rsp HTTP/1.1 Host: {hostname} Content-Type: application/sep+xml Content-Length: {contentLength} <Response xmlns="http://zigbee.org/sep"> <createdDateTime>1234560</createdDateTime> <endDeviceLFDI>C0FFEE00</endDeviceLFDI> <status>1</status> <subject>CAFEFEED</subject> </Response>
7 Response Server replies with Status 201 Created: HTTP/1.1 201 Created
8 Client begins the event at the defined start Time.
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 269 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description 9 Client POST a Response with a Status of "Event Started" to the Response resource specified by the
replyTo field in the EndDeviceControl.
Client sends the following: POST /rsp HTTP/1.1 Host: {hostname} Content-Type: application/sep+xml Content-Length: {contentLength} <Response xmlns="http://zigbee.org/sep"> <createdDateTime>1234900</createdDateTime> <endDeviceLFDI>C0FFEE00</endDeviceLFDI> <status>2</status> <subject>CAFEFEED</subject> </Response>
10 Response Server Responds with Status 201 Created: HTTP/1.1 201 Created
11 Client completes the event.
12 Client POST a Response with a Status of "Event Completed" to the Response resource specified by the replyTo field in the EndDeviceControl.
Client sends the following: POST /rsp HTTP/1.1 Host: {hostname} Content-Type: application/sep+xml Content-Length: {contentLength} <Response xmlns="http://zigbee.org/sep"> <createdDateTime>1235260</createdDateTime> <endDeviceLFDI>C0FFEE00</endDeviceLFDI> <status>3</status> <subject>CAFEFEED</subject> </Response>
13 Response Server Responds with Status 201 Created: HTTP/1.1 201 Created
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 270 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
16.8 Demand Response: Cancel 7787
7788
Figure 16-8: Demand Response - Cancel 7789
Table 16-10 POX Example: Demand Response - Cancel. 7790
Step Description 1 (Same as Demand Response: General)
2 (Same as Demand Response: General)
3 (Same as Demand Response: General)
4 (Same as Demand Response: General)
5 (Same as Demand Response: General)
6 (Same as Demand Response: General)
7 (Same as Demand Response: General)
8 (Same as Demand Response: General)
9 (Same as Demand Response: General)
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 271 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description 10 (Same as Demand Response: General)
11 Client GETs a specific EndDeviceControl from the DRLC Server to check on the current Status of the event it's executing. This should happen on a periodic basis to check if the control is cancelled.
Client sends the following request: GET /drp/1/edc/3 HTTP/1.1 Host: {hostname} Accept: application/sep+xml
12 DemandResponse Server indicates the event is cancelled: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <EndDeviceControl href="/drp/1/edc/3" replyTo="{hostname}/rsp" responseRequired="01" subscribable="0" xmlns="http://zigbee.org/sep"> <mRID>CAFEFEED</mRID> <description>Emergency One Hour Coffee Brew</description> <creationTime>1234556</creationTime> <EventStatus> <currentStatus>2</currentStatus> <dateTime>1234960</dateTime> <potentiallySuperseded>false</potentiallySuperseded> <reason>Caffeine Overload</reason> </EventStatus> <interval> <duration>360</duration> <start>1234900</start> </interval> <randomizeDuration>60</randomizeDuration> <randomizeStart>60</randomizeStart> <deviceCategory>0008</deviceCategory> <drProgramMandatory>true</drProgramMandatory> <loadShiftForward>true</loadShiftForward> <SetPoint> <heatingSetpoint>10000</heatingSetpoint> </SetPoint> </EndDeviceControl>
13 Client cancels the event.
14 Client responds with the specific instance of the EndDeviceControl with an updated EventStatus of 'Canceled'
Server sends the following response: POST /rsp HTTP/1.1 Host: {hostname} Content-Type: application/sep+xml Content-Length: {contentLength} <Response xmlns="http://zigbee.org/sep"> <createdDateTime>1235100</createdDateTime> <endDeviceLFDI>C0FFEE00</endDeviceLFDI> <status>6</status> <subject>CAFEFEED</subject> </Response>
15 Response Server replies with Status 201 Created: HTTP/1.1 201 Created
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 272 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
16.9 Distributed Energy Resource: General 7791
7792
Figure 16-9: Distributed Energy Resource: General 7793
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 273 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Table 16-11 POX Example: Distributed Energy Resource - General. 7794
Step Description 1 The client discovers a server of its EndDevice instance and GETs its FunctionSetAssignments (FSA). Through its
FSA the client discovers it is enrolled in a DERProgram (enrollment occurs out of band). The client registers with the specified DER program server if a secure connection is required.
2 Client GETs the DERProgramList specified in its FSA. Client sends the following request, in this case indicating that it can accept either EXI or XML: GET /derp HTTP/1.1 Host: {hostname} Accept: application/sep+xml; level=+S0
3 The DER server responds with the requested DERProgram list, for example: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <DERProgramList xmlns="http://zigbee.org/sep" href="/derp" all="1" results="1"> <DERProgram href="/derp/0"> <mRID>01BE7A7E57</mRID> <description>Example DER Program</description> <DERControlListLink all="2" href="/derp/0/derc" /> <primacy>2</primacy> </DERProgram> </DERProgramList>
4 The client locates or creates a local Notification resource that can be used to receive notification of changes to the DERControlList.
5 The client POSTs the URI of the Notification resource, together with the DERContolListLink it read from the DERProgram, to the subscription list of its EndDevice instance on the DER server. POST /edev/0/sub HTTP/1.1 Host: {hostname} Content-Type: application/sep+xml Content-Length: {contentLength} <Subscription xmlns="http://zigbee.org/sep"> <subscribedResource>http://server.example.com/derp/0/derc</subscribedResource> <encoding>0</encoding> <level>+S0</level> <limit>0</limit> <notificationURI>http://client.example.com/ntfy</notificationURI> </Subscription>
6 The DER server responds with Status 201 Created. In the future, the DER server will "push" DERControlList updates to the client. HTTP/1.1 201 CREATED Location: /edev/0/sub/1 Content-Length: 0
7 Client GETs the list of DERControls from the DER server. Client sends the following request, in this case asking for the first element of the list: GET /derp/0/derc?s=0&l=1 HTTP/1.1 Host: {hostname}
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 274 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Accept: application/sep+xml; level=+S0 8 DER server responds with the first DERControl on the list.
Server sends the following response: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <DERControlList xmlns="http://zigbee.org/sep" all="2" href="/derp/0/derc" results="1" subscribable="1"> <DERControl> <mRID>02BE7A7E57</mRID> <description>Example DERControl 1</description> <creationTime>1341446390</creationTime> <EventStatus> <currentStatus>1</currentStatus> <dateTime>1341532800</dateTime> <potentiallySuperseded>false</potentiallySuperseded> </EventStatus> <interval> <duration>86400</duration> <start>1341446400</start> </interval> <randomizeDuration>180</randomizeDuration> <randomizeStart>180</randomizeStart> <DERControlBase> <opModVoltVAr href="/derp/0/dc/3"/> </DERControlBase> </DERControl> </DERControlList>
9 The DERControl above calls for dynamic (curve-based) Volt-VAr control mode. The specified curve URI is "/derp/0/dc/3". The client GETs the DERCurve: GET /derp/0/dc/3 HTTP/1.1 Host: {hostname} Accept: application/sep+xml; level=+S0
10 The DER server responds with the requested DERCurve. Client should check the curveType to ensure it is Volt-VAr. In this example (see Figure 12-2) the delivered reactive power remains at 50% of statVArAvail (positive sign indicates delivered or over-excited, yRefType==3 indicates %statVArAvail) as long as the effective percent voltage is at or below 99% of nominal. When the voltage is at 100% of nominal, no reactive power is delivered. As the voltage climbs above nominal, reactive power is received (negative sign indicates under-excited). Voltage may jitter slightly within the dead band created by the four curve points without affecting the reactive power output. HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <DERCurve xmlns="http://zigbee.org/sep" href="/derp/0/dc/3"> <mRID>04BE7A7E57</mRID> <description>An example Volt-VAr curve</description> <creationTime>1341446380</creationTime> <CurveData> <xvalue>99</xvalue> <yvalue>50</yvalue> </CurveData> <CurveData> <xvalue>103</xvalue> <yvalue>-50</yvalue> </CurveData> <CurveData>
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 275 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
<xvalue>101</xvalue> <yvalue>-50</yvalue> </CurveData> <CurveData> <xvalue>97</xvalue> <yvalue>50</yvalue> </CurveData> <curveType>0</curveType> <rampDecTms>600</rampDecTms> <rampIncTms>600</rampIncTms> <rampPT1Tms>10</rampPT1Tms> <xMultiplier>0</xMultiplier> <yMultiplier>0</yMultiplier> <yRefType>3</yRefType> </DERCurve>
11 For each DERControl with ResponseRequired Bit 0 set, the Client POSTs a Response with a Status of "Message Received" to the Response resource specified by the replyTo field in the DERControl. Client sends the following: POST /rsp HTTP/1.1 Host: {hostname} Content-Type: application/sep+xml Content-Length: {contentLength} <Response xmlns="http://zigbee.org/sep"> <createdDateTime>1341507000</createdDateTime> <endDeviceLFDI>C0FFEE00</endDeviceLFDI> <status>1</status> <subject>0002BE7A7E57</subject> </Response>
12 Response Server responds with: HTTP/1.1 201 Created
13 Client begins the event at the specified start (or current) time.
14 Client POSTs a Response with a Status of "Event Started" to the Response resource specified by the replyTo field in the DERControl. Client sends the following: POST /rsp HTTP/1.1 Host: {hostname} Content-Type: application/sep+xml Content-Length: {contentLength} <Response xmlns="http://zigbee.org/sep"> <createdDateTime>1341507010</createdDateTime> <endDeviceLFDI>C0FFEE00</endDeviceLFDI> <status>2</status> <subject>0002BE7A7E57</subject> </Response>
15 Response Server responds with: HTTP/1.1 201 Created
16 Client completes the event.
17 Client POST a Response with a Status of "Event Completed" to the Response resource specified by the replyTo field in the DERControl. Client sends the following: POST /rsp HTTP/1.1 Host: {hostname} Content-Type: application/sep+xml Content-Length: {contentLength}
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 276 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
<Response xmlns="http://zigbee.org/sep"> <createdDateTime>1341532810</createdDateTime> <endDeviceLFDI>C0FFEE00</endDeviceLFDI> <status>3</status> <subject>0002BE7A7E57</subject> </Response>
18 Response Server responds with: HTTP/1.1 201 Created
16.10 Metering: Reading 7795
This is a use case where a metering function set client (e.g., In-Premises Display) queries a reading from a 7796 usage point. For this example, we will assume the meter is configured for 4 TOU tiers and no Blocks and 7797 that we want to read the current tier 3 consumption. 7798
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 277 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
7799
Figure 16-10: Meter Reading 7800
Note: In most cases, registration is required to obtain access to metering. 7801
Table 16-12 POX Example: Meter Reading. 7802
Step Description 1 Client GETs the UsagePointList from the Metering Server
Note: If directed through FunctionsSetAssignments to a particular UsagePoint, these first two steps would be skipped.
Client sends the following request: GET /upt HTTP/1.1 Host: {hostname} Accept: application/sep+xml
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 278 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description 2 Metering Server replies with UsagePointList.
A typical response looks like: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <UsagePointList all="1" href="/upt" results="1" subscribable="0" xmlns="http://zigbee.org/sep"> <UsagePoint href="/upt/0"> <mRID>0B00006CC8</mRID> <description>Usage Point</description> <roleFlags>12</roleFlags> <serviceCategoryKind>0</serviceCategoryKind> <status>1</status> <MeterReadingListLink all="6" href="/upt/0/mr"/> </UsagePoint> </UsagePointList>
3 Client GETs the MeterReadingList from the Metering Server.
Note: This and the next 3 steps may be repeated for each page required to read the entire list. For this example, we are requesting up to 10 MeterReadings at a time. Subsequent GETs would increment the "s" query parameter by 10 or however many list items are returned.
Client sends the following request: GET /upt/0/mr?s=0&l=10 HTTP/1.1 Host: {hostname} Accept: application/sep+xml
4 Metering Server replies with up to 10 MeterReadingList instances. Only 6 are returned in this case as indicated by the MeterReadingListLink "all" attribute in step 2.
A typical response looks like: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <MeterReadingList all="6" href="/upt/0/mr" results="6" subscribable="0" xmlns="http://zigbee.org/sep"> <MeterReading href="/upt/0/mr/0"> <mRID>0C00006CC8</mRID> <description>Cumulative Reading for Wh</description> <ReadingSetListLink all="1" href="/upt/0/mr/0/rs"/> <ReadingTypeLink href="/upt/0/mr/0/rt"/> </MeterReading> <MeterReading href="/upt/0/mr/1"> <mRID>0E00006CC8</mRID> <description>Cumulative Reading for VAR's</description> <ReadingSetListLink all="1" href="/upt/0/mr/1/rs"/> <ReadingTypeLink href="/upt/0/mr/1/rt"/> </MeterReading> <MeterReading href="/upt/0/mr/2"> <mRID>1000006CC8</mRID> <description>Interval Reading for Wh</description> <ReadingSetListLink all="24" href="/upt/0/mr/2/rs"/> <ReadingTypeLink href="/upt/0/mr/2/rt"/> </MeterReading> <MeterReading href="/upt/0/mr/3"> <mRID>1200006CC8</mRID> <description>Interval Reading for VAR's</description> <ReadingSetListLink all="24" href="/upt/0/mr/3/rs"/>
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 279 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description <ReadingTypeLink href="/upt/0/mr/3/rt"/> </MeterReading> <MeterReading href="/upt/0/mr/4"> <mRID>1400006CC8</mRID> <description>Instantaneous Reading for Wh</description> <ReadingLink href="/upt/0/mr/4/r"/> <ReadingTypeLink href="/upt/0/mr/4/rt"/> </MeterReading> <MeterReading href="/upt/0/mr/5"> <mRID>1500006CC8</mRID> <description>Instataneous Reading for VAR's</description> <ReadingLink href="/upt/0/mr/5/r"/> <ReadingTypeLink href="/upt/0/mr/5/rt"/> </MeterReading> </MeterReadingList>
5 Client GETs the ReadingType from the Metering Server.
Note: Step 5 and step 6 may be repeated for each MeterReading returned in step 4 to identify the MeterReading of interest by iterating through the MeterReadings returned in step 4.
Client sends the following request: GET /upt/0/mr/0/rt HTTP/1.1 Host: {hostname} Accept: application/sep+xml
6 Metering Server replies with ReadingType.
A typical response looks like: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <ReadingType href="/upt/0/mr/0/rt" xmlns="http://zigbee.org/sep"> <accumulationBehaviour>9</accumulationBehaviour> <commodity>1</commodity> <dataQualifier>0</dataQualifier> <flowDirection>1</flowDirection> <kind>12</kind> <numberOfConsumptionBlocks>1</numberOfConsumptionBlocks> <numberOfTouTiers>4</numberOfTouTiers> <phase>40</phase> <powerOfTenMultiplier>3</powerOfTenMultiplier> <uom>72</uom> </ReadingType>
Note: Once the desired ReadingType is identified we proceed to the next step.
7 Client GETs the ReadingSetList from the Metering Server.
Note: Because the ReadingSet resources are ordered by their timePeriod earliest time first, we can read the first ReadingSet to get the current values. If a particular historic value is desired you would traverse the ReadingSetList looking for the ReadingSet with the appropriate time stamp.
Client sends the following request:
GET /upt/0/mr/0/rs?s=0&l=4 HTTP/1.1 Host: {hostname} Accept: application/sep+xml
8 Metering Server replies with ReadingSetList with the ReadingSet of interest.
A typical response looks like: HTTP/1.1 200 OK
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 280 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description Content-Type: application/sep+xml Content-Length: {contentLength} <ReadingSetList all="24" href="/upt/0/mr/2/rs" results="4" subscribable="0" xmlns="http://zigbee.org/sep"> <ReadingSet href="/upt/0/mr/2/rs/2"> <mRID>2000006CC8</mRID> <description>Reading Set for WHrs</description> <timePeriod> <duration>3600</duration> <start>1338842400</start> </timePeriod> <ReadingListLink all="12" href="/upt/0/mr/2/rs/2/r"/> </ReadingSet> <ReadingSet href="/upt/0/mr/2/rs/4"> <mRID>2200006CC8</mRID> <description>Reading Set for WHrs</description> <timePeriod> <duration>3600</duration> <start>1338846000</start> </timePeriod> <ReadingListLink all="12" href="/upt/0/mr/2/rs/4/r"/> </ReadingSet> <ReadingSet href="/upt/0/mr/2/rs/6"> <mRID>2400006CC8</mRID> <description>Reading Set for WHrs</description> <timePeriod> <duration>3600</duration> <start>1338849600</start> </timePeriod> <ReadingListLink all="12" href="/upt/0/mr/2/rs/6/r"/> </ReadingSet> <ReadingSet href="/upt/0/mr/2/rs/8"> <mRID>2600006CC8</mRID> <description>Reading Set for WHrs</description> <timePeriod> <duration>3600</duration> <start>1338853200</start> </timePeriod> <ReadingListLink all="12" href="/upt/0/mr/2/rs/8/r"/> </ReadingSet> </ReadingSetList>
9 Client GETs the ReadingList from the Metering Server.
Note: Because the Reading resources are ordered by their touTier and remembering the first element is the total Reading, we can read the fourth (index 3) reading to get the current tier three value.
Client sends the following request:
GET /upt/0/mr/0/rs/0/r?s=3&l=12 HTTP/1.1 Host: {hostname} Accept: application/sep+xml
10 Metering Server replies with ReadingList with the Reading of interest.
A typical response looks like: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <ReadingList all="12" href="/upt/0/mr/2/rs/4/r" results="12" xmlns="http://zigbee.org/sep"> <Reading href="/upt/0/mr/2/rs/4/r/0"> <value>1163</value>
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 281 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description <localID>00</localID> </Reading> <Reading href="/upt/0/mr/2/rs/4/r/2"> <value>1162</value> <localID>01</localID> </Reading> <Reading href="/upt/0/mr/2/rs/4/r/4"> <value>1163</value> <localID>02</localID> </Reading> <Reading href="/upt/0/mr/2/rs/4/r/6"> <value>1163</value> <localID>03</localID> </Reading> <Reading href="/upt/0/mr/2/rs/4/r/8"> <value>1163</value> <localID>04</localID> </Reading> <Reading href="/upt/0/mr/2/rs/4/r/a"> <value>1163</value> <localID>05</localID> </Reading> <Reading href="/upt/0/mr/2/rs/4/r/c"> <value>1162</value> <localID>06</localID> </Reading> <Reading href="/upt/0/mr/2/rs/4/r/e"> <value>1163</value> <localID>07</localID> </Reading> <Reading href="/upt/0/mr/2/rs/4/r/10"> <value>1163</value> <localID>08</localID> </Reading> <Reading href="/upt/0/mr/2/rs/4/r/12"> <value>1163</value> <localID>09</localID> </Reading> <Reading href="/upt/0/mr/2/rs/4/r/14"> <value>1162</value> <localID>0A</localID> </Reading> <Reading href="/upt/0/mr/2/rs/4/r/16"> <value>1163</value> <localID>0B</localID> </Reading> </ReadingList>
16.11 Metering: Interval 7803
This is a use case where a metering function set client (e.g., In-Premises Display) queries for a specific set 7804 of interval readings from a usage point. For this example, we will assume that the meter is configured for 7805 5 minute intervals. 7806
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 282 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
7807
Figure 16-11: Metering Interval 7808
Note: In most cases, registration is required to obtain access to metering. 7809
Table 16-13 POX Example: Metering Interval. 7810
Step Description 1 Client GETs the UsagePointList from the Metering Server.
Note: If directed through FunctionsSetAssignments to a particular UsagePoint, these first two steps would be skipped.
Client sends the following request: GET /upt HTTP/1.1 Host: {hostname} Accept: application/sep+xml
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 283 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description 2 Metering Server replies with UsagePointList.
A typical response looks like: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <UsagePointList all="1" href="/upt" results="1" subscribable="0" xmlns="http://zigbee.org/sep"> <UsagePoint href="/upt/0"> <mRID>0B00006CC8</mRID> <description>Usage Point</description> <roleFlags>12</roleFlags> <serviceCategoryKind>0</serviceCategoryKind> <status>1</status> <MeterReadingListLink all="6" href="/upt/0/mr"/> </UsagePoint> </UsagePointList>
3 Client GETs the MeterReadingList from the Metering Server.
Note: This and the next 3 steps may be repeated for each page required to read the entire list. For this example, we are requesting up to 10 MeterReadings at a time. Subsequent GETs would increment the "s" query parameter by 10 or however many list items are returned.
Client sends the following request: GET /upt/0/mr?s=0&l=10 HTTP/1.1 Host: {hostname} Accept: application/sep+xml
4 Metering Server replies with up to 10 MeterReadingList instances. Only 6 are returned in this case as indicated by the MeterReadingListLink "all" attribute in step 2.
A typical response looks like: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <MeterReadingList all="6" href="/upt/0/mr" results="6" subscribable="0" xmlns="http://zigbee.org/sep"> <MeterReading href="/upt/0/mr/0"> <mRID>0C00006CC8</mRID> <description>Cumulative Reading for Wh</description> <ReadingSetListLink all="1" href="/upt/0/mr/0/rs"/> <ReadingTypeLink href="/upt/0/mr/0/rt"/> </MeterReading> <MeterReading href="/upt/0/mr/1"> <mRID>0E00006CC8</mRID> <description>Cumulative Reading for VAR's</description> <ReadingSetListLink all="1" href="/upt/0/mr/1/rs"/> <ReadingTypeLink href="/upt/0/mr/1/rt"/> </MeterReading> <MeterReading href="/upt/0/mr/2"> <mRID>1000006CC8</mRID> <description>Interval Reading for Wh</description> <ReadingSetListLink all="24" href="/upt/0/mr/2/rs"/> <ReadingTypeLink href="/upt/0/mr/2/rt"/> </MeterReading> <MeterReading href="/upt/0/mr/3"> <mRID>1200006CC8</mRID> <description>Interval Reading for VAR's</description> <ReadingSetListLink all="24" href="/upt/0/mr/3/rs"/>
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 284 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description <ReadingTypeLink href="/upt/0/mr/3/rt"/> </MeterReading> <MeterReading href="/upt/0/mr/4"> <mRID>1400006CC8</mRID> <description>Instantaneous Reading for Wh</description> <ReadingLink href="/upt/0/mr/4/r"/> <ReadingTypeLink href="/upt/0/mr/4/rt"/> </MeterReading> <MeterReading href="/upt/0/mr/5"> <mRID>00000000000000000000001500006CC8</mRID> <description>Instataneous Reading for VAR's</description> <ReadingLink href="/upt/0/mr/5/r"/> <ReadingTypeLink href="/upt/0/mr/5/rt"/> </MeterReading> </MeterReadingList>
5 Client GETs the ReadingType from the Metering Server.
Note: Step 5 and step 6 may be repeated for each MeterReading returned in step 4 to identify the MeterReading of interest by iterating through the MeterReadings returned in step 4.
Client sends the following request: GET /upt/0/mr/0/rt?s=0&l=1 HTTP/1.1 Host: {hostname} Accept: application/sep+xml
6 Metering Server replies with ReadingType.
A typical response looks like: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <ReadingType href="/upt/0/mr/0/rt" xmlns="http://zigbee.org/sep"> <accumulationBehaviour>9</accumulationBehaviour> <commodity>1</commodity> <dataQualifier>0</dataQualifier> <flowDirection>1</flowDirection> <kind>12</kind> <numberOfConsumptionBlocks>1</numberOfConsumptionBlocks> <numberOfTouTiers>4</numberOfTouTiers> <phase>40</phase> <powerOfTenMultiplier>3</powerOfTenMultiplier> <uom>72</uom> </ReadingType>
Note: Once the desired ReadingType is identified we proceed to the next step.
7 Client GETs the ReadingSetList from the Metering Server.
Note: Because a particular historic sequence of values is desired you would traverse the ReadingSetList looking for the ReadingSet with the timePeriod that encompasses the starting time of the range of intervals of interest.
Client sends the following request: GET /upt/0/mr/2/rs?s=0&l=4 HTTP/1.1 Host: {hostname} Accept: application/sep+xml
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 285 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description 8 Metering Server replies with ReadingSetList with the ReadingSet of interest.
A typical response looks like: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <ReadingSetList all="24" href="/upt/0/mr/2/rs" results="4" subscribable="0" xmlns="http://zigbee.org/sep"> <ReadingSet href="/upt/0/mr/2/rs/2"> <mRID>2000006CC8</mRID> <description>Reading Set for WHrs</description> <timePeriod> <duration>3600</duration> <start>1338842400</start> </timePeriod> <ReadingListLink all="12" href="/upt/0/mr/2/rs/2/r"/> </ReadingSet> <ReadingSet href="/upt/0/mr/2/rs/4"> <mRID>2200006CC8</mRID> <description>Reading Set for WHrs</description> <timePeriod> <duration>3600</duration> <start>1338846000</start> </timePeriod> <ReadingListLink all="12" href="/upt/0/mr/2/rs/4/r"/> </ReadingSet> <ReadingSet href="/upt/0/mr/2/rs/6"> <mRID>2400006CC8</mRID> <description>Reading Set for WHrs</description> <timePeriod> <duration>3600</duration> <start>1338849600</start> </timePeriod> <ReadingListLink all="12" href="/upt/0/mr/2/rs/6/r"/> </ReadingSet> <ReadingSet href="/upt/0/mr/2/rs/8"> <mRID>2600006CC8</mRID> <description>Reading Set for WHrs</description> <timePeriod> <duration>3600</duration> <start>1338853200</start> </timePeriod> <ReadingListLink all="12" href="/upt/0/mr/2/rs/8/r"/> </ReadingSet> </ReadingSetList>
9 Once the ReadingSet that encompasses the starting time is identified, the client would GET the ReadingList from the Metering Server.
Note: To identify the interval that has the desired start time the client would GET the reading set.
Client sends the following request:
GET /upt/0/mr/2/rs/4/r?s=0&l=12 HTTP/1.1 Host: {hostname} Accept: application/sep+xml
10 Metering Server replies with ReadingList.
A typical response looks like: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength}
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 286 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description <ReadingList all="12" href="/upt/0/mr/2/rs/4/r" results="12" xmlns="http://zigbee.org/sep"> <Reading href="/upt/0/mr/2/rs/4/r/0"> <value>1163</value> <localID>00</localID> </Reading> <Reading href="/upt/0/mr/2/rs/4/r/2"> <value>1162</value> <localID>01</localID> </Reading> <Reading href="/upt/0/mr/2/rs/4/r/4"> <value>1163</value> <localID>02</localID> </Reading> <Reading href="/upt/0/mr/2/rs/4/r/6"> <value>1163</value> <localID>03</localID> </Reading> <Reading href="/upt/0/mr/2/rs/4/r/8"> <value>1163</value> <localID>04</localID> </Reading> <Reading href="/upt/0/mr/2/rs/4/r/a"> <value>1163</value> <localID>05</localID> </Reading> <Reading href="/upt/0/mr/2/rs/4/r/c"> <value>1162</value> <localID>06</localID> </Reading> <Reading href="/upt/0/mr/2/rs/4/r/e"> <value>1163</value> <localID>07</localID> </Reading> <Reading href="/upt/0/mr/2/rs/4/r/10"> <value>1163</value> <localID>08</localID> </Reading> <Reading href="/upt/0/mr/2/rs/4/r/12"> <value>1163</value> <localID>09</localID> </Reading> <Reading href="/upt/0/mr/2/rs/4/r/14"> <value>1162</value> <localID>0A</localID> </Reading> <Reading href="/upt/0/mr/2/rs/4/r/16"> <value>1163</value> <localID>0B</localID> </Reading> </ReadingList>
The client would then walk the list starting at the "start" time in the timePeriod of the ReadingSet and adding, for readings that specify their timePeriod, the duration or for Readings that don't specify their timePeriod the intervalLength from ReadingType. If all intervals of interest are not contained in the current reading set then we repeat the last two steps to get the additional data. If the information gathered in step 7 is exhausted then you need to loop back to step 7 to GET the next set of ReadingSets.
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 287 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
16.12 Metering: Instantaneous 7811
This is a use case where a metering function set client (e.g., In-Premises Display) queries an 7812 instantaneous Watts reading from a usage point. 7813
7814
Figure 16-12: Metering Instantaneous 7815
Note: In most cases, registration is required to obtain access to metering. 7816
Table 16-14 POX Example: Metering Instantaneous. 7817
Step Description 1 Client GETs the UsagePointList from the Metering Server
Note: If directed through FunctionsSetAssignments to a particular UsagePoint, these first two steps would be skipped.
Client sends the following request: GET /upt HTTP/1.1 Host: {hostname} Accept: application/sep+xml
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 288 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description 2 Metering Server replies with UsagePointList.
A typical response looks like: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <UsagePointList all="1" href="/upt" results="1" subscribable="0" xmlns="http://zigbee.org/sep"> <UsagePoint href="/upt/0"> <mRID>0B00006CC8</mRID> <description>Usage Point</description> <roleFlags>12</roleFlags> <serviceCategoryKind>0</serviceCategoryKind> <status>1</status> <MeterReadingListLink all="6" href="/upt/0/mr"/> </UsagePoint> </UsagePointList>
3 Client GETs the MeterReadingList from the Metering Server.
Note: This and the next 3 steps may be repeated for each page required to read the entire list. For this example, we are requesting up to 10 MeterReadings at a time. Subsequent GETs would increment the "s" query parameter by 10 or however many list items are returned.
Client sends the following request: GET /upt/0/mr?s=0&l=10 HTTP/1.1 Host: {hostname} Accept: application/sep+xml
4 Metering Server replies with up to 10 MeterReading instances. Only 6 are returned in this case as indicated by the MeterReadingListLink "all" attribute in step 2.
A typical response looks like: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <MeterReadingList all="6" href="/upt/0/mr" results="6" subscribable="0" xmlns="http://zigbee.org/sep"> <MeterReading href="/upt/0/mr/0"> <mRID>0C00006CC8</mRID> <description>Cumulative Reading for Wh</description> <ReadingSetListLink all="1" href="/upt/0/mr/0/rs"/> <ReadingTypeLink href="/upt/0/mr/0/rt"/> </MeterReading> <MeterReading href="/upt/0/mr/1"> <mRID>0E00006CC8</mRID> <description>Cumulative Reading for VAR's</description> <ReadingSetListLink all="1" href="/upt/0/mr/1/rs"/> <ReadingTypeLink href="/upt/0/mr/1/rt"/> </MeterReading> <MeterReading href="/upt/0/mr/2"> <mRID>1000006CC8</mRID> <description>Interval Reading for Wh</description> <ReadingSetListLink all="24" href="/upt/0/mr/2/rs"/> <ReadingTypeLink href="/upt/0/mr/2/rt"/> </MeterReading> <MeterReading href="/upt/0/mr/3"> <mRID>1200006CC8</mRID> <description>Interval Reading for VAR's</description> <ReadingSetListLink all="24" href="/upt/0/mr/3/rs"/>
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 289 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description <ReadingTypeLink href="/upt/0/mr/3/rt"/> </MeterReading> <MeterReading href="/upt/0/mr/4"> <mRID>1400006CC8</mRID> <description>Instantaneous Reading for Wh</description> <ReadingLink href="/upt/0/mr/4/r"/> <ReadingTypeLink href="/upt/0/mr/4/rt"/> </MeterReading> <MeterReading href="/upt/0/mr/5"> <mRID>00000000000000000000001500006CC8</mRID> <description>Instataneous Reading for VAR's</description> <ReadingLink href="/upt/0/mr/5/r"/> <ReadingTypeLink href="/upt/0/mr/5/rt"/> </MeterReading> </MeterReadingList>
5 Client GETs the ReadingType from the Metering Server.
Note: Step 5 and step 6 may be repeated for each MeterReading returned in step 4 to identify the MeterReading of interest by iterating through the MeterReadings returned in step 4.
Client sends the following request: GET /upt/0/mr/4/rt HTTP/1.1 Host: {hostname} Accept: application/sep+xml
6 Metering Server replies with ReadingType.
A typical response looks like: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <ReadingType href="/upt/0/mr/4/rt" xmlns="http://zigbee.org/sep"> <accumulationBehaviour>12</accumulationBehaviour> <commodity>1</commodity> <dataQualifier>0</dataQualifier> <flowDirection>1</flowDirection> <kind>12</kind> <numberOfConsumptionBlocks>0</numberOfConsumptionBlocks> <numberOfTouTiers>0</numberOfTouTiers> <phase>40</phase> <powerOfTenMultiplier>3</powerOfTenMultiplier> <uom>38</uom> </ReadingType> Note: Once the desired ReadingType is identified we proceed to the next step.
7 Client GETs the Reading from the Metering Server.
Note: Because the instantaneous value is in the resource indicated in the ReadingLink of MeterReading we can read that resource.
Client sends the following request: GET /upt/0/mr/4/r HTTP/1.1 Host: {hostname} Accept: application/sep+xml
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 290 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description 8 Metering Server replies with the Reading.
A typical response looks like: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <Reading href="/upt/0/mr/4/r" xmlns="http://zigbee.org/sep"> <value>14</value> </Reading>
Note: Subsequent reads of this URI will return more recent data. If a GET fails on this resource then this entire procedure would be repeated to reestablish the correct URI.
16.13 Metering: Mirroring 7818
This is a use case where a mirror metering function set client (e.g., a gas meter) POSTs first its general 7819 information and then its data. It also shows a client of the gas meter data retrieving the most recent 24 7820 intervals of data. An assumption is made that prior to this sequence the mirror client has discovered the 7821 URI of the appropriate Meter Mirroring Server. 7822
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 291 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
7823
Figure 16-13: Meter Mirroring 7824
Note: In most cases, registration is required to obtain access to metering and meter mirroring. 7825
Table 16-15 POX Example: Meter Mirroring. 7826
Step Description
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 292 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description 1 Meter Mirroring Client POSTs a MirrorUsagePoint to the Mirror Metering Server. It is including the
current consumption value. This could have been done in a separate POST to the resultant MirrorUsagePoint.
Note: It passes two ReadingType definitions, one for Summation and one for Interval data.
Client sends the following request: POST /mup HTTP/1.1 Host: {hostname} Content-Type: application/sep+xml Content-Length: {contentLength} <MirrorUsagePoint xmlns="http://zigbee.org/sep"> <mRID>0600006CC8</mRID> <description>Gas Mirroring</description> <roleFlags>13</roleFlags> <serviceCategoryKind>1</serviceCategoryKind> <status>1</status> <deviceLFDI>3E4F45AB31EDFE5B67E343E5E4562E31984E23E5</deviceLFDI> <MirrorMeterReading> <mRID>0700006CC8</mRID> <description>Cumulative Reading for Gas</description> <Reading> <value>125</value> </Reading> <ReadingType> <accumulationBehaviour>9</accumulationBehaviour> <commodity>7</commodity> <dataQualifier>0</dataQualifier> <flowDirection>1</flowDirection> <powerOfTenMultiplier>3</powerOfTenMultiplier> <uom>119</uom> </ReadingType> </MirrorMeterReading> <MirrorMeterReading> <mRID>0800006CC8</mRID> <description>Interval Readings for Gas</description> <ReadingType> <accumulationBehaviour>4</accumulationBehaviour> <commodity>7</commodity> <dataQualifier>0</dataQualifier> <flowDirection>1</flowDirection> <powerOfTenMultiplier>3</powerOfTenMultiplier> <uom>119</uom> </ReadingType> </MirrorMeterReading> </MirrorUsagePoint>
2 Mirror Metering Server creates a MirrorUsagePoint and UsagePoint with the data supplied in the MirrorUsagePoint, adds it to its MirrorUsagePointList and then replies with the URI of the MirrorUsagePoint.
A typical response looks like: HTTP/1.1 201 Created Content-Length: 0 Location: /mup/0
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 293 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description 3 Meter Mirroring Client POSTs a MirrorMeterReading to the Mirror Metering Server.
Client sends the following request: POST /mup/0 HTTP/1.1 Host: {hostname} Content-Type: application/sep+xml Content-Length: {contentLength} <MirrorMeterReading xmlns="http://zigbee.org/sep"> <mRID>0800006CC8</mRID> <MirrorReadingSet> <mRID>0900006CC8</mRID> <timePeriod> <duration>86400</duration> <start>1341579365</start> </timePeriod> <Reading> <value>9</value> <localID>00</localID> </Reading> <Reading> <value>11</value> <localID>01</localID> </Reading> <Reading> <value>10</value> <localID>02</localID> </Reading> <Reading> <value>13</value> <localID>03</localID> </Reading> <Reading> <value>12</value> <localID>04</localID> </Reading> <Reading> <value>11</value> <localID>05</localID> </Reading> <Reading> <value>10</value> <localID>06</localID> </Reading> <Reading> <value>16</value> <localID>07</localID> </Reading> <Reading> <value>9</value> <localID>08</localID> </Reading> <Reading> <value>7</value> <localID>09</localID> </Reading> <Reading> <value>6</value> <localID>0A</localID> </Reading> <Reading> <value>5</value> <localID>0B</localID> </Reading>
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 294 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description <Reading> <value>8</value> <localID>0C</localID> </Reading> <Reading> <value>9</value> <localID>0D</localID> </Reading> <Reading> <value>10</value> <localID>0E</localID> </Reading> <Reading> <value>12</value> <localID>0F</localID> </Reading> <Reading> <value>14</value> <localID>10</localID> </Reading> <Reading> <value>13</value> <localID>11</localID> </Reading> <Reading> <value>11</value> <localID>12</localID> </Reading> <Reading> <value>7</value> <localID>13</localID> </Reading> <Reading> <value>8</value> <localID>14</localID> </Reading> <Reading> <value>10</value> <localID>15</localID> </Reading> <Reading> <value>10</value> <localID>16</localID> </Reading> <Reading> <value>10</value> <localID>17</localID> </Reading> </MirrorReadingSet> </MirrorMeterReading>
4 Mirror Metering Server creates a MirrorMeterReading with the data supplied in the MirrorUsagePoint and then replies with the URI of the MirrorMeterReading.
A typical response looks like: HTTP/1.1 201 Created Content-Length: 0 Location: /upt/1/mr
Note: Steps 1-4 could be combined into 2 steps by including the initial interval reading set data in the initial MirrorUsagePoint POST.
5 Mirror Data Client GETs the UsagePointList from the Metering Server
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 295 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description Note: If directed through FunctionsSetAssignments to a particular UsagePoint, these first two steps would be skipped.
Client sends the following request: GET /upt HTTP/1.1 Host: {hostname} Accept: application/sep+xml
6 Mirror Metering Server replies with UsagePointList.
A typical response looks like: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <UsagePointList all="2" href="/upt" results="2" subscribable="0" xmlns="http://zigbee.org/sep"> <UsagePoint href="/upt/0"> <mRID>0B00006CC8</mRID> <description>Usage Point</description> <roleFlags>12</roleFlags> <serviceCategoryKind>0</serviceCategoryKind> <status>1</status> <MeterReadingListLink all="6" href="/upt/0/mr"/> </UsagePoint> <UsagePoint href="/upt/1"> <mRID>0C00006CC8</mRID> <description>Usage Point</description> <roleFlags>13</roleFlags> <serviceCategoryKind>1</serviceCategoryKind> <status>1</status> <MeterReadingListLink all="2" href="/upt/1/mr"/> </UsagePoint> </UsagePointList>
7 Mirror Data Client GETs the MeterReadingList from the Mirror Metering Server.
Note: We will choose /upt/1 because its role flags indicate it is a mirror.
Note: This and the next 3 steps may be repeated for each page required to read the entire list. For this example, we are requesting up to 10 MeterReadings at a time. Subsequent GETs would increment the "s" query parameter by 10 or however many list items are returned.
Client sends the following request: GET /upt/1/mr?s=0&l=10 HTTP/1.1 Host: {hostname} Accept: application/sep+xml
8 Mirror Metering Server replies with up to 10 MeterReadingList instances. Only 2 are returned in this case as indicated by the MeterReadingListLink "all" attribute in step 6.
A typical response looks like: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <MeterReadingList all="2" href="/upt/1/mr" results="2" subscribable="0" xmlns="http://zigbee.org/sep"> <MeterReading href="/upt/1/mr/0"> <mRID>0700006CC8</mRID> <description>Cumulative Reading for Gas</description> <ReadingLink href="/upt/1/mr/0/r"/>
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 296 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description <ReadingTypeLink href="/upt/1/mr/0/rt"/> </MeterReading> <MeterReading href="/upt/1/mr/1"> <mRID>0800006CC8</mRID> <description> Interval Readings for Gas</description> <ReadingSetListLink all="1" href="/upt/1/mr/1/rs"/> <ReadingTypeLink href="/upt/1/mr/1/rt"/> </MeterReading> </MeterReadingList>
9 Mirror Data Client GETs the ReadingType from the Mirror Metering Server.
Note: Step 9 and step 10 may be repeated for each MeterReading returned in step 4 to identify the MeterReading of interest by iterating through the MeterReadings returned in step 4.
Client sends the following request: GET /upt/1/mr/1/rt HTTP/1.1 Host: {hostname} Accept: application/sep+xml
10 Mirror Metering Server replies with ReadingType.
A typical response looks like: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <ReadingType href="/upt/1/mr/1/rt" xmlns="http://zigbee.org/sep"> <accumulationBehaviour>4</accumulationBehaviour> <commodity>7</commodity> <flowDirection>1</flowDirection> <powerOfTenMultiplier>3</powerOfTenMultiplier> <uom>119</uom> </ReadingType>
Note: Once the desired ReadingType is identified we proceed to the next step.
11 Mirror Data Client GETs the ReadingSetList from the Metering Server.
Note: Because the ReadingSet resources are ordered by their timePeriod earliest time first, we can read the first ReadingSet to get the current values. If a particular historic value is desired you would traverse the ReadingSetList looking for the ReadingSet with the appropriate time stamp.
Client sends the following request:
GET /upt/1/mr/1/rs?s=0&l=1 HTTP/1.1 Host: {hostname} Accept: application/sep+xml
12 Mirror Metering Server replies with ReadingSetList with the ReadingSet of interest.
A typical response looks like: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <ReadingSetList all="1" href="/upt/1/mr/1/rs" results="1" subscribable="0" xmlns="http://zigbee.org/sep"> <ReadingSet href="/upt/1/mr/1/rs/32"> <mRID>2000006CC8</mRID> <timePeriod> <duration>86400</duration> <start>1341579365</start>
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 297 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description </timePeriod> <ReadingListLink all="24" href="/upt/1/mr/1/rs/32/r"/> </ReadingSet> </ReadingSetList>
13 Mirror Data Client GETs the ReadingList from the Mirror Metering Server.
Client sends the following request:
GET /upt/1/mr/1/rs/32/r?s=0&l=24 HTTP/1.1 Host: {hostname} Accept: application/sep+xml
14 Mirror Metering Server replies with ReadingList with the Reading of interest.
A typical response looks like: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <ReadingList all="24" href="/upt/1/mr/1/rs/32/r" results="24" xmlns="http://zigbee.org/sep"> <Reading href="/upt/1/mr/1/rs/32/r/4"> <value>9</value> <localID>00</localID> </Reading> <Reading href="/upt/1/mr/1/rs/32/r/5"> <value>11</value> <localID>01</localID> </Reading> <Reading href="/upt/1/mr/1/rs/32/r/6"> <value>10</value> <localID>02</localID> </Reading> <Reading href="/upt/1/mr/1/rs/32/r/7"> <value>13</value> <localID>03</localID> </Reading> <Reading href="/upt/1/mr/1/rs/32/r/8"> <value>12</value> <localID>04</localID> </Reading> <Reading href="/upt/1/mr/1/rs/32/r/9"> <value>11</value> <localID>05</localID> </Reading> <Reading href="/upt/1/mr/1/rs/32/r/a"> <value>10</value> <localID>06</localID> </Reading> <Reading href="/upt/1/mr/1/rs/32/r/b"> <value>16</value> <localID>07</localID> </Reading> <Reading href="/upt/1/mr/1/rs/32/r/c"> <value>9</value> <localID>08</localID> </Reading> <Reading href="/upt/1/mr/1/rs/32/r/d"> <value>7</value> <localID>09</localID> </Reading> <Reading href="/upt/1/mr/1/rs/32/r/e"> <value>6</value>
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 298 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description <localID>0A</localID> </Reading> <Reading href="/upt/1/mr/1/rs/32/r/f"> <value>5</value> <localID>0B</localID> </Reading> <Reading href="/upt/1/mr/1/rs/32/r/10"> <value>8</value> <localID>0C</localID> </Reading> <Reading href="/upt/1/mr/1/rs/32/r/11"> <value>9</value> <localID>0D</localID> </Reading> <Reading href="/upt/1/mr/1/rs/32/r/12"> <value>10</value> <localID>0E</localID> </Reading> <Reading href="/upt/1/mr/1/rs/32/r/13"> <value>12</value> <localID>0F</localID> </Reading> <Reading href="/upt/1/mr/1/rs/32/r/14"> <value>14</value> <localID>10</localID> </Reading> <Reading href="/upt/1/mr/1/rs/32/r/15"> <value>13</value> <localID>11</localID> </Reading> <Reading href="/upt/1/mr/1/rs/32/r/16"> <value>11</value> <localID>12</localID> </Reading> <Reading href="/upt/1/mr/1/rs/32/r/17"> <value>7</value> <localID>13</localID> </Reading> <Reading href="/upt/1/mr/1/rs/32/r/0"> <value>8</value> <localID>14</localID> </Reading> <Reading href="/upt/1/mr/1/rs/32/r/1"> <value>10</value> <localID>15</localID> </Reading> <Reading href="/upt/1/mr/1/rs/32/r/2"> <value>10</value> <localID>16</localID> </Reading> <Reading href="/upt/1/mr/1/rs/32/r/3"> <value>10</value> <localID>17</localID> </Reading> </ReadingList>
15 The next day, the Meter Mirroring Client POSTs a MirrorMeterReadingList with MirrorMeterReadings to the Mirror Metering Server. The first MirrorMeterReading is the consumption (cumulative) value and the second MirrorMeterReading is a set of interval data.
Client sends the following request: POST /mup/0 HTTP/1.1 Host: {hostname}
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 299 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description Content-Type: application/sep+xml Content-Length: {contentLength} <MirrorMeterReadingList xmlns="http://zigbee.org/sep"> <MirrorMeterReading> <mRID>0700006CC8</mRID> <Reading> <value>574</value> </Reading> </MirrorMeterReading> <MirrorMeterReading> <mRID>0800006CC8</mRID> <MirrorReadingSet> <mRID>0900006CC8</mRID> <timePeriod> <duration>86400</duration> <start>1341665765</start> </timePeriod> <Reading> <value>9</value> <localID>00</localID> </Reading> <Reading> <value>12</value> <localID>01</localID> </Reading> <Reading> <value>10</value> <localID>02</localID> </Reading> <Reading> <value>13</value> <localID>03</localID> </Reading> <Reading> <value>11</value> <localID>04</localID> </Reading> <Reading> <value>11</value> <localID>05</localID> </Reading> <Reading> <value>10</value> <localID>06</localID> </Reading> <Reading> <value>12</value> <localID>07</localID> </Reading> <Reading> <value>9</value> <localID>08</localID> </Reading> <Reading> <value>7</value> <localID>09</localID> </Reading> <Reading> <value>6</value> <localID>0A</localID> </Reading> <Reading> <value>5</value> <localID>0B</localID>
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 300 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description </Reading> <Reading> <value>8</value> <localID>0C</localID> </Reading> <Reading> <value>9</value> <localID>0D</localID> </Reading> <Reading> <value>10</value> <localID>0E</localID> </Reading> <Reading> <value>12</value> <localID>0F</localID> </Reading> <Reading> <value>14</value> <localID>10</localID> </Reading> <Reading> <value>13</value> <localID>11</localID> </Reading> <Reading> <value>11</value> <localID>12</localID> </Reading> <Reading> <value>7</value> <localID>13</localID> </Reading> <Reading> <value>8</value> <localID>14</localID> </Reading> <Reading> <value>10</value> <localID>15</localID> </Reading> <Reading> <value>10</value> <localID>16</localID> </Reading> <Reading> <value>10</value> <localID>17</localID> </Reading> </MirrorReadingSet> </MirrorMeterReading>
16 Mirror Metering Server copies the data supplied into the corresponding UsagePoint and then replies with the URI of the MeterReadingList of that UsagePoint.
A typical response looks like: HTTP/1.1 201 Created Content-Length: 0 Location: /upt/1/mr
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 301 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description 17 Mirror Data Client GETs the ReadingSetList from the Mirror Metering Server.
Note: Because the Client cached the URI of the reading set list, it can skip ahead to this step.
Client sends the following request:
GET /upt/1/mr/1/rs?s=0&l=1 HTTP/1.1 Host: {hostname} Accept: application/sep+xml
18 Mirror Metering Server replies with ReadingSetList with the ReadingSet of interest.
A typical response looks like: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <ReadingSetList all="1" href="/upt/1/mr/1/rs" results="1" subscribable="0" xmlns="http://zigbee.org/sep"> <ReadingSet href="/upt/1/mr/1/rs/33"> <mRID>A000006CC8</mRID> <timePeriod> <duration>86400</duration> <start>1341665765</start> </timePeriod> <ReadingListLink all="24" href="/upt/1/mr/1/rs/33/r"/> </ReadingSet> </ReadingSetList>
19 Mirror Data Client GETs the ReadingList from the Mirror Metering Server.
Client sends the following request: GET /upt/1/mr/1/rs/33/r?s=0&l=24 HTTP/1.1 Host: {hostname} Accept: application/sep+xml
20 Mirror Metering Server replies with ReadingList with the Reading of interest.
A typical response looks like: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <ReadingList all="12" href="/upt/1/mr/1/rs/33/r" results="24" xmlns="http://zigbee.org/sep"> <Reading href="/upt/1/mr/1/rs/33/r/4"> <value>9</value> <localID>00</localID> </Reading> <Reading href="/upt/1/mr/1/rs/33/r/5"> <value>12</value> <localID>01</localID> </Reading> <Reading href="/upt/1/mr/1/rs/33/r/6"> <value>10</value> <localID>02</localID> </Reading> <Reading href="/upt/1/mr/1/rs/33/r/7"> <value>13</value> <localID>03</localID> </Reading> <Reading href="/upt/1/mr/1/rs/33/r/8"> <value>11</value> <localID>04</localID>
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 302 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description </Reading> <Reading href="/upt/1/mr/1/rs/33/r/9"> <value>11</value> <localID>05</localID> </Reading> <Reading href="/upt/1/mr/1/rs/33/r/a"> <value>10</value> <localID>06</localID> </Reading> <Reading href="/upt/1/mr/1/rs/33/r/b"> <value>12</value> <localID>07</localID> </Reading> <Reading href="/upt/1/mr/1/rs/33/r/c"> <value>9</value> <localID>08</localID> </Reading> <Reading href="/upt/1/mr/1/rs/33/r/d"> <value>7</value> <localID>09</localID> </Reading> <Reading href="/upt/1/mr/1/rs/33/r/e"> <value>6</value> <localID>0A</localID> </Reading> <Reading href="/upt/1/mr/1/rs/33/r/f"> <value>5</value> <localID>0B</localID> </Reading> <Reading href="/upt/1/mr/1/rs/33/r/10"> <value>8</value> <localID>0C</localID> </Reading> <Reading href="/upt/1/mr/1/rs/33/r/11"> <value>9</value> <localID>0D</localID> </Reading> <Reading href="/upt/1/mr/1/rs/33/r/12"> <value>10</value> <localID>0E</localID> </Reading> <Reading href="/upt/1/mr/1/rs/33/r/13"> <value>12</value> <localID>0F</localID> </Reading> <Reading href="/upt/1/mr/1/rs/33/r/14"> <value>14</value> <localID>10</localID> </Reading> <Reading href="/upt/1/mr/1/rs/33/r/15"> <value>13</value> <localID>11</localID> </Reading> <Reading href="/upt/1/mr/1/rs/33/r/16"> <value>11</value> <localID>12</localID> </Reading> <Reading href="/upt/1/mr/1/rs/33/r/17"> <value>7</value> <localID>13</localID> </Reading> <Reading href="/upt/1/mr/1/rs/33/r/0"> <value>8</value> <localID>14</localID> </Reading>
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 303 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description <Reading href="/upt/1/mr/1/rs/33/r/1"> <value>10</value> <localID>15</localID> </Reading> <Reading href="/upt/1/mr/1/rs/33/r/2"> <value>10</value> <localID>16</localID> </Reading> <Reading href="/upt/1/mr/1/rs/33/r/3"> <value>10</value> <localID>17</localID> </Reading> </ReadingList>
16.14 Pricing: Time of Use 7827
This flow diagram describes pricing client device obtaining pricing information. 7828
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 304 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
7829
Figure 16-14: Pricing Time of Use 7830
Note: In most cases, registration is required to obtain access to pricing, and the client is directed to a 7831 specific TariffProfile through a Link in the FunctionSetAssignments found in their EndDevice 7832 FunctionSetAssignmentsListLink, or from a different function set such as Billing. 7833
Table 16-16 POX Example: Pricing TOU. 7834
Step Description 1 Client GETs the TariffProfile from the Pricing Server.
Client sends the following request: GET /tp/3 HTTP/1.1 Host: {hostname} Accept: application/sep+xml
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 305 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description 2 Pricing server responds with the TariffProfile.
Server sends the following response: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <TariffProfile href="/tp/3" xmlns="http://zigbee.org/sep"> <mRID>799794f4620b17e00000e566</mRID> <description>PEV TOU Rate</description> <currency>840</currency> <pricePowerOfTenMultiplier>-6</pricePowerOfTenMultiplier> <primacy>0</primacy> <rateCode>TOU-D-PEV Baseline 6</rateCode> <RateComponentListLink all="1" href="/tp/3/rc"/> <serviceCategoryKind>0</serviceCategoryKind> </TariffProfile>
3 Client GETs the RateComponentList from the Pricing Server.
Client sends the following request: GET /tp/3/rc?l=1 HTTP/1.1 Host: {hostname} Accept: application/sep+xml
4 Pricing server responds with the RateComponentList.
Server sends the following response: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <RateComponentList all="1" href="/tp/3/rc" results="1" xmlns="http://zigbee.org/sep"> <RateComponent href="/tp/3/rc/3"> <mRID>fc000b07143d24fc0000e566</mRID> <description>TOU-D-PEV</description> <ActiveTimeTariffIntervalListLink all="0" href="/tp/3/rc/3/acttti"/> <flowRateEndLimit> <multiplier>0</multiplier> <unit>38</unit> <value>400</value> </flowRateEndLimit> <flowRateStartLimit> <multiplier>0</multiplier> <unit>38</unit> <value>0</value> </flowRateStartLimit> <ReadingTypeLink href="/rt/1"/> <roleFlags>12</roleFlags> <TimeTariffIntervalListLink all="5" href="/tp/3/rc/3/tti"/> </RateComponent> </RateComponentList>
5 Client GETs the ReadingType from the Pricing Server.
Client sends the following request: GET /rt/1 HTTP/1.1 Host: {hostname} Accept: application/sep+xml
6 Pricing server responds with the ReadingType.
Server sends the following response:
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 306 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <ReadingType href="/rt/1" xmlns="http://zigbee.org/sep"> <accumulationBehaviour>4</accumulationBehaviour> <commodity>1</commodity> <dataQualifier>12</dataQualifier> <flowDirection>1</flowDirection> <intervalLength>3600</intervalLength> <kind>12</kind> <numberOfConsumptionBlocks>1</numberOfConsumptionBlocks> <numberOfTouTiers>3</numberOfTouTiers> <phase>0</phase> <powerOfTenMultiplier>3</powerOfTenMultiplier> <tieredConsumptionBlocks>false</tieredConsumptionBlocks> <uom>72</uom> </ReadingType>
7 Client GETs the TimeTariffIntervalList from the Pricing Server.
Client sends the following request: GET /tp/3/rc/3/tti?l=5 HTTP/1.1 Host: {hostname} Accept: application/sep+xml
8 Pricing server responds with the TimeTariffIntervalList.
Server sends the following response: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <TimeTariffIntervalList all="5" href="/tp/3/rc/3/tti" results="5" subscribable="1" xmlns="http://zigbee.org/sep"> <TimeTariffInterval href="/tp/3/rc/3/tti/5" subscribable="1"> <mRID>ef06fa23dc0a0f650000e566</mRID> <description>Off-Peak 1</description> <creationTime>1357430400</creationTime> <EventStatus> <currentStatus>0</currentStatus> <dateTime>1357430400</dateTime> <potentiallySuperseded>false</potentiallySuperseded> </EventStatus> <interval> <duration>28800</duration> <start>1357516800</start> </interval> <randomizeDuration>300</randomizeDuration> <randomizeStart>300</randomizeStart> <ConsumptionTariffIntervalListLink all="1" href="/tp/3/rc/3/tti/5/cti"/> <touTier>1</touTier> </TimeTariffInterval> <TimeTariffInterval href="/tp/3/rc/3/tti/6" subscribable="1"> <mRID>41fc7c07e16820770000e566</mRID> <description>Mid-Peak 1</description> <creationTime>1357430400</creationTime> <EventStatus> <currentStatus>0</currentStatus> <dateTime>1357430400</dateTime> <potentiallySuperseded>false</potentiallySuperseded> </EventStatus> <interval>
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 307 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description <duration>14400</duration> <start>1357545600</start> </interval> <randomizeDuration>300</randomizeDuration> <randomizeStart>300</randomizeStart> <ConsumptionTariffIntervalListLink all="1" href="/tp/3/rc/3/tti/6/cti"/> <touTier>2</touTier> </TimeTariffInterval> <TimeTariffInterval href="/tp/3/rc/3/tti/7" subscribable="1"> <mRID>63eed7b30c1c87a40000e566</mRID> <description>On-Peak</description> <creationTime>1357430400</creationTime> <EventStatus> <currentStatus>0</currentStatus> <dateTime>1357430400</dateTime> <potentiallySuperseded>false</potentiallySuperseded> </EventStatus> <interval> <duration>21600</duration> <start>1357552800</start> </interval> <randomizeDuration>300</randomizeDuration> <randomizeStart>300</randomizeStart> <ConsumptionTariffIntervalListLink all="1" href="/tp/3/rc/3/tti/7/cti"/> <touTier>3</touTier> </TimeTariffInterval> <TimeTariffInterval href="/tp/3/rc/3/tti/8" subscribable="1"> <mRID>9b04f0713e9212d90000e566</mRID> <description>Mid-Peak 2</description> <creationTime>1357430400</creationTime> <EventStatus> <currentStatus>0</currentStatus> <dateTime>1357430400</dateTime> <potentiallySuperseded>false</potentiallySuperseded> </EventStatus> <interval> <duration>18000</duration> <start>1357574400</start> </interval> <randomizeDuration>300</randomizeDuration> <randomizeStart>300</randomizeStart> <ConsumptionTariffIntervalListLink all="1" href="/tp/3/rc/3/tti/8/cti"/> <touTier>2</touTier> </TimeTariffInterval> <TimeTariffInterval href="/tp/3/rc/3/tti/9" subscribable="1"> <mRID>c13c8755dc39b5950000e566</mRID> <description>Off-Peak 2</description> <creationTime>1357430400</creationTime> <EventStatus> <currentStatus>0</currentStatus> <dateTime>1357430400</dateTime> <potentiallySuperseded>false</potentiallySuperseded> </EventStatus> <interval> <duration>10800</duration> <start>1357592400</start> </interval> <randomizeDuration>300</randomizeDuration> <randomizeStart>300</randomizeStart> <ConsumptionTariffIntervalListLink all="1" href="/tp/3/rc/3/tti/9/cti"/> <touTier>1</touTier> </TimeTariffInterval> </TimeTariffIntervalList>
9 Client GETs a ConsumptionTariffIntervalList from the Pricing Server (note that there is a
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 308 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description ConsumptionTariffIntervalList for each TimeTariffInterval, but only one is shown below.)
Client sends the following request: GET /tp/3/rc/3/tti/5/cti?l=1 HTTP/1.1 Host: {hostname} Accept: application/sep+xml
10 Pricing server responds with the ConsumptionTariffIntervalList.
Server sends the following response: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <ConsumptionTariffIntervalList all="1" href="/tp/3/rc/3/tti/5/cti" results="1" xmlns="http://zigbee.org/sep"> <ConsumptionTariffInterval href="/tp/3/rc/3/tti/5/cti/1"> <consumptionBlock>1</consumptionBlock> <price>113000</price> <startValue>0</startValue> </ConsumptionTariffInterval> </ConsumptionTariffIntervalList>
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 309 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
16.15 Billing: Billing Period 7835
This flow diagram describes a billing client device obtaining billing information including billing period. 7836
7837
Figure 16-15: Billing Period 7838
Note: In most cases, registration is required to obtain access to billing, and the client is directed to a 7839 specific CustomerAccount through a Link in the FunctionSetAssignments found in their EndDevice 7840 FunctionSetAssignmentsListLink. 7841
Table 16-17 POX Example: Billing Period. 7842
Step Description 1 Client GETs the CustomerAccount from the Billing Server.
Client sends the following request: GET /ca/1 HTTP/1.1 Host: {hostname} Accept: application/sep+xml
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 310 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description 2 Billing server responds with the CustomerAccount.
Server sends the following response: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <CustomerAccount href="/bill/1" xmlns="http://zigbee.org/sep"> <mRID>26d0c9722dd639ab0000e566</mRID> <description/> <currency>840</currency> <customerAccount>981273648</customerAccount> <CustomerAgreementListLink all="1" href="/bill/1/ca"/> <customerName>John Doe</customerName> <pricePowerOfTenMultiplier>-6</pricePowerOfTenMultiplier> <ServiceSupplierLink href="/ss"/> </CustomerAccount>
3 Client GETs the ServiceSupplier from the Billing Server.
Client sends the following request: GET /ss HTTP/1.1 Host: {hostname} Accept: application/sep+xml
4 Billing server responds with the ServiceSupplier.
Server sends the following response: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <ServiceSupplier href="/ss" xmlns="http://zigbee.org/sep"> <mRID>cac046d1ee2a332a0000e566</mRID> <description>Watts R Us</description> <email>[email protected]</email> <phone>888.555.1212</phone> <providerID>58726</providerID> <web>www.WattsRus.com</web> </ServiceSupplier>
5 Client GETs the CustomerAgreementList from the Billing Server.
Client sends the following request: GET /bill/1/ca HTTP/1.1 Host: {hostname} Accept: application/sep+xml
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 311 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description 6 Billing server responds with the CustomerAgreementList.
Server sends the following response: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <CustomerAgreementList all="1" href="/bill/1/ca" results="1" subscribable="0" xmlns="http://zigbee.org/sep"> <CustomerAgreement href="/bill/1/ca/1"> <mRID>65f839fc951345e70000e566</mRID> <description>Electric Service - 4/1/2012</description> <ActiveBillingPeriodListLink all="1" href="/bill/1/ca/1/actbp"/> <BillingPeriodListLink all="1" href="/bill/1/ca/1/bp"/> <HistoricalReadingListLink all="1" href="/bill/1/ca/1/ver"/> <ProjectionReadingListLink all="1" href="/bill/1/ca/1/pro"/> <serviceLocation>Acct. XXX-XXXXX-384 (Elm St.)</serviceLocation> <TariffProfileLink href="/tp/3"/> <UsagePointLink href="/upt/1"/> </CustomerAgreement> </CustomerAgreementList>
7 Client GETs the BillingPeriodList from the Billing Server.
Client sends the following request: GET /bill/1/ca/1/bp?l=1 HTTP/1.1 Host: {hostname} Accept: application/sep+xml
8 Billing server responds with the BillingPeriodList.
Server sends the following response: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <BillingPeriodList all="2" href="/bill/1/ca/1/bp" results="1" subscribable="1" xmlns="http://zigbee.org/sep"> <BillingPeriod href="/bill/1/ca/1/bp"> <billLastPeriod>140730000</billLastPeriod> <billToDate>83550000</billToDate> <interval> <duration>2419200</duration> <start>1360195200</start> </interval> <statusTimeStamp>1361577600</statusTimeStamp> </BillingPeriod> </BillingPeriodList>
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 312 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
16.16 Billing: Historical 7843
This flow diagram describes a billing client device obtaining historical billing readings. 7844
7845
Figure 16-16: Billing Historical 7846
Table 16-18 POX Example: Billing Historical. 7847
Step Description 1 Client GETs the HistoricalReadingList from the Billing Server.
Client sends the following request: GET /bill/1/ca/1/ver HTTP/1.1 Host: {hostname} Accept: application/sep+xml
2 Billing server responds with the HistoricalReadingList.
Server sends the following response: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <HistoricalReadingList all="1" href="/bill/1/ca/1/ver" results="1"
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 313 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description xmlns="http://zigbee.org/sep"> <HistoricalReading href="/bill/1/ca/1/ver/1"> <mRID>ce7f99f087b5e3de0000e566</mRID> <description>Hourly usage (kWh)</description> <BillingReadingSetListLink all="180" href="/bill/1/ca/1/ver/1/brs"/> <ReadingTypeLink href="/rt/3"/> </HistoricalReading> </HistoricalReadingList>
3 Client GETs the ReadingType from the Billing Server.
Client sends the following request: GET /rt/3 HTTP/1.1 Host: {hostname} Accept: application/sep+xml
4 Billing server responds with the ReadingType.
Server sends the following response: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <ReadingType href="/rt/3" xmlns="http://zigbee.org/sep"> <accumulationBehaviour>4</accumulationBehaviour> <commodity>1</commodity> <dataQualifier>12</dataQualifier> <flowDirection>1</flowDirection> <intervalLength>3600</intervalLength> <kind>12</kind> <numberOfConsumptionBlocks>2</numberOfConsumptionBlocks> <numberOfTouTiers>3</numberOfTouTiers> <phase>0</phase> <powerOfTenMultiplier>0</powerOfTenMultiplier> <tieredConsumptionBlocks>false</tieredConsumptionBlocks> <uom>72</uom> </ReadingType>
5 Client GETs the BillingReadingSetList from the Billing Server.
Client sends the following request: GET /bill/1/ca/1/ver/1/brs?l=1 HTTP/1.1 Host: {hostname} Accept: application/sep+xml
6 Billing server responds with the BillingReadingSetList.
Server sends the following response: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <BillingReadingSetList all="180" href="/bill/1/ca/1/ver/1/brs" results="1" subscribable="1" xmlns="http://zigbee.org/sep"> <BillingReadingSet href="/bill/1/ca/1/ver/1/brs/1"> <mRID>82866ecc81c9638a0000e566</mRID> <timePeriod> <duration>86400</duration> <start>1361491200</start> </timePeriod> <BillingReadingListLink all="24" href="/bill/1/ca/1/ver/1/brs/1/br"/> </BillingReadingSet> </BillingReadingSetList>
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 314 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description 7 Client GETs the BillingReadingList from the Billing Server.
Client sends the following request: GET /bill/1/ca/1/ver/1/brs/1/br?l=1 HTTP/1.1 Host: {hostname} Accept: application/sep+xml
8 Billing server responds with the BillingReadingList.
Server sends the following response: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <BillingReadingList all="24" href="/bill/1/ca/1/ver/1/brs/1/br" results="1" xmlns="http://zigbee.org/sep"> <BillingReading href="/bill/1/ca/1/ver/1/brs/1/br/1"> <consumptionBlock>0</consumptionBlock> <qualityFlags>01</qualityFlags> <timePeriod> <duration>3600</duration> <start>1361491200</start> </timePeriod> <touTier>3</touTier> <value>38</value> <Charge> <kind>0</kind> <value>429400</value> </Charge> </BillingReading> </BillingReadingList>
7848
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 315 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
16.17 Billing: Projection 7849
This flow diagram describes a billing client device obtaining a billing projection. 7850
7851
Figure 16-17: Billing Projection 7852
Table 16-19 POX Example: Billing Projection. 7853
Step Description 1 Client GETs the ProjectionReadingList from the Billing Server.
Client sends the following request: GET /bill/1/ca/1/pro HTTP/1.1 Host: {hostname} Accept: application/sep+xml
2 Billing server responds with the ProjectionReadingList.
Server sends the following response: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <ProjectionReadingList all="2" href="/bill/1/ca/1/pro" results="1" xmlns="http://zigbee.org/sep"> <ProjectionReading href="/bill/1/ca/1/pro/1"> <mRID>d0b05a2e65144fca0000e566</mRID> <description>Billing Projections</description> <BillingReadingSetListLink all="1" href="/bill/1/ca/1/pro/1/brs"/> </ProjectionReading> </ProjectionReadingList>
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 316 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description 3 Client GETs the BillingReadingSetList from the Billing Server.
Client sends the following request: GET /bill/1/ca/1/pro/1/brs?l=1 HTTP/1.1 Host: {hostname} Accept: application/sep+xml
4 Billing server responds with the BillingReadingSetList.
Server sends the following response: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <BillingReadingSetList all="1" href="/bill/1/ca/1/pro/1/brs" results="1" subscribable="1" xmlns="http://zigbee.org/sep"> <BillingReadingSet href="/bill/1/ca/1/pro/1/brs/1"> <mRID>7cb8a5b136a9618e0000e566</mRID> <description>Start Consumption Block 2</description> <timePeriod> <duration>2419200</duration> <start>1360195200</start> </timePeriod> <BillingReadingListLink all="1" href="/bill/1/ca/1/pro/1/brs/1/br"/> </BillingReadingSet> </BillingReadingSetList>
5 Client GETs the BillingReadingList from the Billing Server.
Client sends the following request: GET /bill/1/ca/1/pro/1/brs/1/br?l=1 HTTP/1.1 Host: {hostname} Accept: application/sep+xml
6 Billing server responds with the BillingReadingList.
Server sends the following response: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: {contentLength} <BillingReadingList all="24" href="/bill/1/ca/1/ver/1/brs/1/br" results="1" xmlns="http://zigbee.org/sep"> <BillingReading href="/bill/1/ca/1/ver/1/brs/1/br/1"> <consumptionBlock>0</consumptionBlock> <qualityFlags>01</qualityFlags> <timePeriod> <duration>3600</duration> <start>1361491200</start> </timePeriod> <touTier>3</touTier> <value>38</value> <Charge> <kind>0</kind> <value>429400</value> </Charge> </BillingReading> </BillingReadingList>
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 317 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
16.18 File Loading 7854
The flow diagram below describes how an LD queries an FS for a list of available files, loads a file from 7855 the FS, and verifies and activates the loaded file. It also describes how the LD may optionally maintain 7856 status of the file loading operation and reporting of same to the FS. The flow assumes network joining 7857 and device registration with service provider have already occurred. 7858
7859
Figure 16-18: File Load - FlowDiagram 7860
Step descriptions are listed below. 7861
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 318 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Table 16-20 File Load: Flow Description 7862
Step Description 1 The LD issues discovery requests to locate available FS (DNS-SD subtype "file"). 2 The LD has discovered the FS and obtained the URL of its FileList. 3 The LD queries the FileList to determine if there are any available files to be downloaded to the LD. An
example FileList query: GET http://host1/fileList?s=0&l=5&type=0x0000&mfId=37244&mfModel=123abc&mfVer=23.47.102 HTTP/1.1
Host: host1
This query directs the FS to return the list of firmware files (type) from manufacturer 37244 (IANA PEN) LD model "123abc" whose version number is greater than (newer than) 23.47.102. As the LFDI and mfHwVer were omitted, they implicitly match any value that may have been specified in the File resources.
4 The FS responds to the LD with the FileList satisfying the query parameters.
An example FS response: HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: …
<FileList all="2" href="http://host1/fileList" results="2" xmlns="http://zigbee.org/sep"> <File href="http://host1/myFile1"> <fileURI>http://host1/myfile1.bin</fileURI> <mfID>37244</mfID> <mfModel>123abc</mfModel> <mfVer>23.48.1</mfVer> <size>128000</size> <type>00</type> </File> <File href="http://host1/myFile2"> <fileURI>http://host1/myfile2.bin</fileURI> <mfID>37244</mfID> <mfModel>123abc</mfModel> <mfVer>23.47.103</mfVer> <size>136000</size> <type>00</type> </File> </FileList>
The FS reports that is has two files which match the initial query for firmware/manufacturer PEN 37244, model "123abc", and are newer than version 23.47.102. The first entry in the list (mfVer 23.48.1) is the latest version.
Note: no activation time was provided. 5 The LD examines the results from the FileList query and determines which, if any, of the File resources
should be loaded. The LD selects the latest file available /myFile1 with version 12.48.1 6 The LD updates its FileStatus resource.
7-8 The LD loads /myFile1 with version 12.48.1. Note: this exchange will often be accomplished with multiple HTTP(S) request/response (using the Range and Content-Range entity headers).
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 319 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description 9 Recall that no activation time was included in the original /myFile1 obtained by the LD from the
FileList. Whenever a LD loads a File with an unspecified activateTime, the LD will continue to poll to aquire a file activateTime (interval and retry discussed above).
The LD will periodically issue the following request: GET http://host1/myFile1 HTTP/1.1 Host: host1
10 The FS responds with /myFile1. HTTP/1.1 200 OK Content-Type: application/sep+xml Content-Length: …
<File href="http://host1/myFile1" xmlns="http://zigbee.org/sep"> <activateTime>3763784682</activateTime> <fileURI>http://host1/myfile1.bin</fileURI> <mfID>37244</mfID> <mfModel>123abc</mfModel> <mfVer>23.48.1</mfVer> <size>128000</size> <type>00</type> </File>
Note that, this time, an activateTime is provided within /myFile1. If there is not an activateTime contained in /myFile1, the LD continues to poll for activateTime.
11 The LD waits until the activation time specified for /myFile1 is reached, then places the file into the activated state. In the case of a firmware file, the file is now the running image.
12 The LD again updates its FileStatus resource. 13 The LD PUTs its FileStatus resource to a remote EndDevice server.
In this example, the EndDevice is hosted at the FS. Thus the FS is provided with a final status of the LD load operation.
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 320 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
16.19 Flow Reservation: General 7863
7864
Figure 16-19: Flow Reservation: General 7865
The following is a summary of the example: 7866
Step 1 - Client (PEV) creates a FlowReservationRequest at 5:00 PM for charging between midnight and 7867 8:00 AM, 12 kWh energy requested at a power level of 7 kW, 7371 seconds duration requested. 7868
� Subsequently, the Server creates a FlowReservationResponse with a charge interval between 7869 1:00 AM and 5:20 AM at 3 kW. 7870
Step 3 - Client requests the FlowReservationResponseList to find the response matching the request. 7871
Step 4 – Server responds with the FlowReservationResponseList. 7872
Step 5 - Client periodically requests the FlowReservationResponse to look for changes. 7873
Step 7 - Client updates PowerStatus periodically during charging. 7874
Note: In most cases, registration is required to obtain access to request flow reservations. 7875
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 321 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Table 16-21 POX Example: Flow Reservation - General. 7876
Step Description 1 Client POSTs a FlowReservationRequest to the Flow Reservation Server at 9/22/2013 5:00 PM.
Client sends the following request: POST /edev/3/frq HTTP/1.1 Host: {hostname} <FlowReservationRequest xmlns="http://zigbee.org/sep"> <mRID>68512866203db3b10000e566</mRID> <description>Charge between 12AM and 8AM</description> <!-- 9/22/2013 5:00 PM GMT --> <creationTime>1379869200</creationTime> <!-- 6171sec charging + 1200sec conditioning --> <durationRequested>7371</durationRequested> <energyRequested> <!-- 12 kWh --> <multiplier>3</multiplier> <value>12</value> </energyRequested> <intervalRequested> <!-- 8 hours --> <duration>28800</duration> <!-- 9/23/2013 12:00 AM GMT --> <start>1379894400</start> </intervalRequested> <powerRequested> <!-- 7 kW --> <multiplier>3</multiplier> <value>7</value> </powerRequested> <RequestStatus> <dateTime>1379869200</dateTime> <!-- Requested --> <requestStatus>0</requestStatus> </RequestStatus> </FlowReservationRequest>
2 Flow Reservation server responds with the FlowReservationRequest location. Server sends the following response: HTTP/1.1 201 Created Location: /edev/3/frq/1
3 Client GETs the FlowReservationResponseList from the Flow Reservation Server to look for a response
to the request.
Client sends the following request: GET /edev/3/frp HTTP/1.1 Host: {hostname}
4 Flow Reservation server responds with the FlowReservationResponseList
Server sends the following response: HTTP/1.1 200 OK Content-Type: application/sep+xml
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 322 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description <FlowReservationResponseList all="1" href="/edev/3/frp" results="1" subscribable="1" xmlns="http://zigbee.org/sep"> <FlowReservationResponse href="/edev/3/frp/1" subscribable="1"> <mRID>f8afa6fde40db98d0000ea75</mRID> <description>Charge between 1AM and 5:20AM</description> <!-- 9/22/2013 5:01 PM GMT --> <creationTime>1379869260</creationTime> <EventStatus> <!-- Scheduled --> <currentStatus>0</currentStatus> <dateTime>1379869260</dateTime> <potentiallySuperseded>false</potentiallySuperseded> </EventStatus> <interval> <!-- 4 hours 20 minutes --> <duration>15600</duration> <!-- 9/23/2013 1:00 AM GMT --> <start>1379898000</start> </interval> <energyAvailable> <multiplier>0</multiplier> <value>12000</value> </energyAvailable> <powerAvailable> <multiplier>0</multiplier> <value>3000</value> </powerAvailable> <subject>68512866203db3b10000e566</subject> </FlowReservationResponse> </FlowReservationResponseList>
5 Client GETs the FlowReservationResponseList periodically (or subscribes) from the Flow Reservation Server.
Client sends the following request: GET /edev/3/frp HTTP/1.1 Host: {hostname}
6 Flow Reservation server responds with the FlowReservationResponseList.
Server sends the following response: HTTP/1.1 200 OK Content-Type: application/sep+xml <FlowReservationResponseList all="1" href="/edev/3/frp" results="1" subscribable="1" xmlns="http://zigbee.org/sep"> <FlowReservationResponse href="/edev/3/frp/1" subscribable="1"> <mRID>f8afa6fde40db98d0000ea75</mRID> <description>Charge between 1AM and 5:20AM</description> <!-- 9/22/2013 5:01 PM GMT --> <creationTime>1379869260</creationTime> <EventStatus> <!-- Scheduled --> <currentStatus>0</currentStatus> <dateTime>1379869260</dateTime> <potentiallySuperseded>false</potentiallySuperseded> </EventStatus> <interval> <!-- 4 hours 20 minutes --> <duration>15600</duration> <!-- 9/23/2013 1:00 AM GMT --> <start>1379898000</start>
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 323 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description </interval> <energyAvailable> <multiplier>0</multiplier> <value>12000</value> </energyAvailable> <powerAvailable> <multiplier>0</multiplier> <value>3000</value> </powerAvailable> <subject>68512866203db3b10000e566</subject> </FlowReservationResponse> </FlowReservationResponseList>
7 From 1:00 AM to 5:20 AM while charging the client periodically updates its PowerStatus.
Client sends the following request: PUT /edev/3/ps HTTP/1.1 Host: {hostname} <PowerStatus xmlns="http://zigbee.org/sep"> <!-- more than LowChargeThreshold remaining --> <batteryStatus>1</batteryStatus> <!-- 9/23/2013 3:00 AM GMT --> <changedTime>1379905200</changedTime> <!-- mains --> <currentPowerSource>1</currentPowerSource> <estimatedChargeRemaining>7000</estimatedChargeRemaining> <PEVInfo> <chargingPowerNow> <multiplier>0</multiplier> <value>3000</value> </chargingPowerNow> <energyRequestNow> <multiplier>0</multiplier> <value>6100</value> </energyRequestNow> <maxForwardPower> <multiplier>3</multiplier> <value>7</value> </maxForwardPower> <!-- 3600sec * 6100Wh/7000W + 1200sec conditioning --> <minimumChargingDuration>4337</minimumChargingDuration> <targetStateOfCharge>10000</targetStateOfCharge> <!-- 9/23/2013 8:00 AM GMT --> <timeChargeIsNeeded>1379923200</timeChargeIsNeeded> <timeChargingStatusPEV>1379905200</timeChargingStatusPEV> </PEVInfo> </PowerStatus>
8 Flow Reservation server responds: HTTP/1.1 204 No Content
7877
7878
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 324 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
16.20 Flow Reservation: Cancel 7879
7880
Figure 16-20: Flow Reservation: Cancel 7881
The following is a summary of the example: 7882
Step 1 - Client (PEV) creates a FlowReservationRequest at 5:00 PM for charging between midnight and 7883 8:00 AM. 7884
� Subsequently, the Server creates a FlowReservationResponse with a charge interval between 7885 1:00 AM and 5:20 AM at 3 kW. 7886
Step 3 – At 1:00 AM the Client wants to change the time the charging is needed and therefore creates a 7887 new FlowReservationRequest for charging between 1:00 AM and 5:00 AM. 7888
� Subsequently, the Server creates a FlowReservationResponse with a charge interval between 7889 1:02 AM and 4:22 AM at 4 kW. 7890
Step 5 - Client cancels the original FlowReservationRequest. 7891
� Subsequently, the Server cancels the original FlowReservationResponse. 7892
Step 7 - Client requests the FlowReservationResponseList. 7893
Step 8 – Server responds with the FlowReservationResponseList, the first FlowReservationResponse is 7894 canceled and the second FlowReservationResponse is Active. 7895
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 325 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Table 16-22 POX Example: Flow Reservation - Cancel 7896
Step Description
1 Client POSTs a FlowReservationRequest to the Flow Reservation Server at 9/22/2013 5:00 PM.
Client sends the following request:
POST /edev/3/frq HTTP/1.1 Host: {hostname} <FlowReservationRequest xmlns="http://zigbee.org/sep"> <mRID>68512866203db3b10000e566</mRID> <description>Charge between 12AM and 8AM</description> <!-- 9/22/2013 5:00 PM GMT --> <creationTime>1379869200</creationTime> <!-- 6171sec charging + 1200sec conditioning --> <durationRequested>7371</durationRequested> <energyRequested> <!-- 12 kWh --> <multiplier>3</multiplier> <value>12</value> </energyRequested> <intervalRequested> <!-- 8 hours --> <duration>28800</duration> <!-- 9/23/2013 12:00 AM GMT --> <start>1379894400</start> </intervalRequested> <powerRequested> <!-- 7 kW --> <multiplier>3</multiplier> <value>7</value> </powerRequested> <RequestStatus> <dateTime>1379869200</dateTime> <!-- Requested --> <requestStatus>0</requestStatus> </RequestStatus> </FlowReservationRequest>
2 Flow Reservation server responds with the FlowReservationRequest location.
Server sends the following response: HTTP/1.1 201 Created Location: /edev/3/frq/1
3 Due to a change in when the vehicle is needed, at 9/23/2013 1:00 AM the client creates a second FlowReservationRequest for charging between 1:00 AM and 5:00 AM. Client sends the following request: POST /edev/3/frq HTTP/1.1 Host: {hostname} <FlowReservationRequest xmlns="http://zigbee.org/sep"> <mRID>68512866203db3b10000e577</mRID> <description>Charge between 1AM and 5AM</description> <!-- 9/23/2013 1:00 AM GMT --> <creationTime>1379898000</creationTime> <!-- 6171sec charging + 1200sec conditioning --> <durationRequested>7371</durationRequested> <energyRequested> <!-- 12 kWh -->
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 326 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description <multiplier>3</multiplier> <value>12</value> </energyRequested> <intervalRequested> <!-- 4 hours --> <duration>14400</duration> <!-- 9/23/2013 1:00 AM GMT --> <start>1379898000</start> </intervalRequested> <powerRequested> <!-- 7 kW --> <multiplier>3</multiplier> <value>7</value> </powerRequested> <RequestStatus> <dateTime>1379898000</dateTime> <!-- Requested --> <requestStatus>0</requestStatus> </RequestStatus> </FlowReservationRequest>
4 Flow Reservation server responds with the FlowReservationRequest location.
Server sends the following response: HTTP/1.1 201 Created Location: /edev/3/frq/2
5 Client PUTs a canceled status to the first FlowReservationRequest. Client sends the following request: PUT /edev/3/frq/1 HTTP/1.1 Host: {hostname} <FlowReservationRequest xmlns="http://zigbee.org/sep"> <mRID>68512866203db3b10000e566</mRID> <description>Charge between 12AM and 8AM</description> <!-- 9/22/2013 5:00 PM --> <creationTime>1379869200</creationTime> <durationRequested>7371</durationRequested> <energyRequested> <multiplier>3</multiplier> <value>12</value> </energyRequested> <intervalRequested> <duration>28800</duration> <start>1379894400</start> </intervalRequested> <powerRequested> <multiplier>3</multiplier> <value>7</value> </powerRequested> <RequestStatus> <!-- 9/23/2013 1:01 AM GMT --> <dateTime>1379898060</dateTime> <!-- Canceled --> <requestStatus>1</requestStatus> </RequestStatus> </FlowReservationRequest>
6 Flow Reservation server sends the following response: HTTP/1.1 204 No Content
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 327 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description
7 Client GETs the FlowReservationResponseList periodically (or subscribes) from the Flow Reservation Server.
Client sends the following request: GET /edev/3/frp?l=2 HTTP/1.1 Host: {hostname}
8 Flow Reservation server responds with the FlowReservationResponseList. The first FlowReservationResponse is Canceled, the second is Active. Server sends the following response: HTTP/1.1 200 OK Content-Type: application/sep+xml <FlowReservationResponseList all="2" href="/edev/3/frp" results="2" subscribable="1" xmlns="http://zigbee.org/sep"> <FlowReservationResponse href="/edev/3/frp/1" subscribable="1"> <mRID>f8afa6fde40db98d0000ea75</mRID> <description>Charge between 1AM and 5:20AM</description> <!-- 9/22/2013 5:01 AM GMT --> <creationTime>1379869260</creationTime> <EventStatus> <!-- Canceled --> <currentStatus>2</currentStatus> <dateTime>1379898060</dateTime> <potentiallySuperseded>true</potentiallySuperseded> </EventStatus> <interval> <!-- 4 hours 20 minutes --> <duration>15600</duration> <!-- 9/23/2013 1:00 AM GMT --> <start>1379898000</start> </interval> <energyAvailable> <multiplier>0</multiplier> <value>12000</value> </energyAvailable> <powerAvailable> <multiplier>0</multiplier> <value>3000</value> </powerAvailable> <subject>68512866203db3b10000e566</subject> </FlowReservationResponse> <FlowReservationResponse href="/edev/3/frp/1" subscribable="1"> <mRID>f8afa6fde40db98d0000ea76</mRID> <description>Charge between 1:02AM and 4:22AM</description> <!-- 9/23/2013 1:02 AM GMT --> <creationTime>1379898120</creationTime> <EventStatus> <!-- Active --> <currentStatus>1</currentStatus> <dateTime>1379898120</dateTime> <potentiallySuperseded>false</potentiallySuperseded> </EventStatus> <interval> <!-- 3 hours 20 minutes --> <duration>12000</duration> <!-- 9/23/2013 1:02 AM GMT --> <start>1379898120</start>
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 328 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Step Description </interval> <energyAvailable> <multiplier>0</multiplier> <value>12000</value> </energyAvailable> <powerAvailable> <multiplier>0</multiplier> <value>4000</value> </powerAvailable> <subject>68512866203db3b10000e577</subject> </FlowReservationResponse> </FlowReservationResponseList>
7897
16.21 Event Randomization 7898
The following are examples of how to set the randomization parameters to accomplish different 7899randomization strategies. The attributes of an event that define its behavior in time are, the "interval" that 7900defines the "start" and "duration" of the event, "randomizeStart" and "randomizeDuration". The later two 7901controlling the randomization behavior. For these examples, we will assume we are looking at DRLC 7902events and that the events are causing reductions in load over a large population. The graphs are 7903indicating the aggregated load for the entire population for a single event. 7904
16.21.1 Simple Event 7905
7906
Figure 16-21: Simple Event - No Ramp Up - No Ramp Down 7907
Note: This use case is NOT targeted for large population control. 7908
Table 16-23 Ramp Value. 7909
Attribute Value (seconds)
start 0 duration 3600 randomizeStart 0 randomizeDuration 0
Time(Minutes)
Load
0 60
No Ramp Down, No Ramp Up
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 329 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
16.21.2 Event with Positive Randomized Duration 7910
7911
7912
Figure 16-22: Event with Positive Randomization Duration 7913
7914
Table 16-24 Event Ramp Time. 7915
Attribute Value (seconds)
start 0 duration 3600 randomizeStart 0 randomizeDuration 300
16.21.3 Event with Positive Randomized Start 7916
7917
7918
7919
7920
7921
7922
7923
0 60 65
N o R a m p D o w n , R a m p U p Po s i ti v e (o r N e g a tiv e )
Load
Time(Minutes)
Time
Load
0 60+5 65
Ramp Down Positive, Ramp Up Positive
Time(Minutes)
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 330 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
7924
Figure 16-23: Event with Positive Randomization Start 7925
Table 16-25 Event Start Time. 7926
Attribute Value (seconds)
start 0 duration 3600 randomizeStart 300 randomizeDuration 0
16.21.4 Event with Negative Randomized Start 7927
7928
Figure 16-24: Event with Negative Randomized Start 7929
7930
7931
Table 16-26 Event Start Time. 7932
Attribute Value (seconds)
start 0 duration 3600 randomizeStart -300 randomizeDuration 0
Time
Load
0 60-5 55
Ramp Down Negative, Ramp Up Negative
Time(Minutes)
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 331 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
16.21.5 Event with Positive Randomization and Finishing in one Hour 7933
7934
Figure 16-25: Positive Randomization in an Hour 7935
Table 16-27 Event Start Time. 7936
Attribute Value (seconds)
start 0 duration 3300
randomizeStart 300 randomizeDuration 0
16.21.6 Event with Negative Randomized Start and at Least One Hour Duration 7937
7938
Figure 16-26: Event with Negative Start in One Hour 7939
Table 16-28 Event Start Time. 7940
Time
Load
0 60+5 55
Ramp Down Positive, Ramp Up Negative
Time
Load
0 60-5 65
Ramp Down Negative, Ramp Up Positive
Attribute Value (seconds)
start 0 duration 3900
Time(Minutes)
Time(Minutes)
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 332 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
7941
7942
16.21.7 Event with Randomized Start and Long Ramp Up 7943
7944
Figure 16-27: Randomized Start and Long Ramp Up 7945
Table 16-29 Event Start Time. 7946
Attribute Value (seconds)
start 0
duration 3600
randomizeStart 300
randomizeDuration 300
7947
randomizeStart -300 randomizeDuration 0
T i me
Load
0 55 60 65 +5
Ramp Down Positive, Random Duration
Time(Minutes)
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 333 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
16.21.8 Event with Positive Randomized Start and Fixed End Time 7948
7949
Figure 16-28: Randomized Start and Fixed End Time 7950
Note: This scenario is NOT possible with the current set of parameters. For grid stability "snap" back on 7951 is not a desirable use case. 7952
Time
Load
0 60+5
Ramp Down Positive (or Negative), No Ramp Up
Time(Minutes)
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 334 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
17 Appendix D – Guidelines [INFORMATIVE] 7953
17.1 Pricing Implementation Guidelines 7954
This section discusses guidelines for implementing common service provider tariff rate designs and 7955 enabling HAN devices to match a TariffProfile.RateComponent.ReadingType with a meaningful 7956 Metering value in cases where the Pricing and Metering servers may not be coordinated or match. 7957
This section assumes readers are familiar with the Pricing and Metering function set text in early sections. 7958 Readers may also wish to consult the WADL and schema [ZB 13-0201] for more detailed information. 7959
17.1.1 Implementing Common Tariff Designs 7960
This section is intended to provide guidance to service providers and HAN server implementers on how to 7961 use the Pricing function set and its design flexibility in a way that encourages standard uses and practices. 7962 High level description of the resources and attribute values are provided here; for detailed XML examples 7963 of the pricing function set, see Section 16.14. The following four tariff rate designs are discussed further 7964 in the text below: 7965
� Flat rate 7966
� Time-of-use tiers 7967
� Consumption-based blocks 7968
� Time-of-use tiers with consumption-based blocks 7969
All four designs will assume that pricing information is only provided for the forward direction 7970 (commodity delivered), and is applicable for any flow rate (demand). This corresponds to a TariffProfile 7971 with a single RateComponent in its RateComponentList. This RateComponent would have the 7972 flowRateStartLimit and flowRateEndLimit attributes elided, and would link to a ReadingType with the 7973 flowDirection attribute set to "1". 7974
17.1.2 Flat Rate Design 7975
The flat rate design assumes a constant price for a commodity over one or many billing periods. With no 7976 price differentiation based on the time of day or on the amount of the commodity already consumed, the 7977 flat-rate design requires only a single touTier and a single consumptionBlock. Therefore the tariff's 7978 RateComponent must link to a ReadingType with the following attributes: 7979
� numberOfConsumptionBlocks = 1 7980
� numberOfTouTiers = 1 7981
Per [ZB 13-0201], the RateComponent links to a TimeTariffIntervalList. The flat rate design only 7982 requires a single TimeTariffInterval in this list, though information for future seasons could be 7983 communicated by providing additional TimeTariffIntervals in the list (only one TimeTariffInterval can be 7984 active at a given time). Any TimeTariffInterval instance provided under a flat rate design must have the 7985 touTier attribute set to "1". 7986
Again per [ZB 13-0201], TimeTariffInterval links to a ConsumptionTariffIntervalList. For the flat rate 7987 design there must only be one ConsumptionTariffInterval in the list. This ConsumptionTariffInterval 7988 defines the consumption price per commodity unit. The startValue attribute in this 7989 ConsumptionTariffInterval must be "0" and the consumptionBlock attribute must be "1". 7990
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 335 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
17.1.3 Time-of-Use Rate Design 7991
Most TOU rate designs consist of a repeating series of time-differentiated rates. These can vary over the 7992 course of a day, and the series may be different on weekdays and weekends. Pricing servers may be 7993 implemented and configured with functionality that creates repeating TimeTariffIntervals based on an 7994 internal schedule in order to minimize backhaul network traffic, but this is out of scope for SEP 2. For the 7995 HAN, such a Pricing server would supply a steady stream of pricing "events" with a defined 7996 commencement and duration. Pricing service providers and their servers are encouraged to provide 7997 enough pricing information to cover the next 24-hour period since most consumer devices operate over 7998 this time scale. Pricing service providers are also encouraged to update their Pricing servers with the next 7999 sequential TimeTariffInterval instance at least four hours before its Effective Start Time. 8000
For this TOU rate example, assume a daily three-tier (plus one Critical Peak Pricing (CPP) tier) rate 8001 design with the following characteristics as shown in Table 17-1: 8002
Table 17-1 TOU Rate. 8003
Time Period Description Price Tier
Midnight – 8 AM Off-peak $0.10 1 8 AM – 10 AM Mid-peak $0.20 2 10 AM – 6 PM On-peak $0.40 3
6 PM – Midnight Mid-peak $0.20 2 Intermittent CPP $0.70 4
Tier numbers are ordered by price from lowest to highest (though note that the price attribute itself will be 8004 found in the ConsumptionTariffInterval resource linked to by a TimeTariffInterval, not in the 8005 TimeTariffInterval itself); this is mandatory in Smart Energy 2.0. 8006
The TOU design provides price differentiation based on the time of day. However, as with the flat rate 8007 design, there is no price differentiation based on the amount of the commodity already consumed. In SEP 8008 2 terms, this means that the TOU design requires two or more touTiers,but must provide only a single 8009 consumptionBlock. Using the above TOU example, the tariff's RateComponent must link to a 8010 ReadingType with the following attributes: 8011
� numberOfConsumptionBlocks = 1 8012
� numberOfTouTiers = 4 8013
Continuing the above example, consider a pricing server configured as follows: 8014
� Server provides 48 hours of price information. 8015
� Price information is updated every midnight. 8016
� The local time is 9 AM on July 16, 2012. 8017
� There are no CPP events scheduled for the next 48 hours. 8018
In this scenario, the server's TimeTariffIntervalList will contain 8 TimeTariffIntervals: one expired event, 8019 one active event, and six scheduled events. Each TimeTariffInterval will link to a 8020 ConsumptionTariffIntervalList, where each list, under a TOU-only design, contains one 8021 ConsumptionTariffInterval. As with the flat rate design, each ConsumptionTariffInterval must have a 8022 consumptionBlock attribute of "1" and a startValue attribute of "0". 8023
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 336 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
17.1.4 Consumption-based Block Rate Design 8024
In some jurisdictions (e.g., California, British Columbia, the UK), consumption-based block rate designs 8025 have been put in place to incentivize efficient consumption of a commodity with prices that ratchet up 8026 over the course of the billing period based on the amount of the commodity consumed. In other scenarios, 8027 typically for commercial and industrial (C&I) customers, the price charged per commodity unit consumed 8028 falls after some usage threshold. 8029
For this consumption-based rate design, assume a five-tier design with the following characteristics in 8030 Table 17-2: 8031
Table 17-2 Consumption-based Rates. 8032
Block Consumption startValue Price
1 0 $0.12 2 150 $0.14 3 250 $0.23 4 300 $0.27 5 350 $0.30
Block numbers are ordered by startValue from lowest to highest; this is mandatory in SEP 2. While the 8033 associated prices in this example also increase with each block number, this is not mandated by SEP 2. 8034 The above example corresponds to a ReadingType with the following attributes: 8035
� numberOfConsumptionBlocks = 5 8036
� numberOfTouTiers = 1 8037
As with the flat rate design, a server using the block rate design may only have one TimeTariffInterval in 8038 the TimeTariffIntervalList linked to from RateComponent. That TimeTariffInterval could correspond to 8039 an entire billing period or longer. However, unlike the flat rate design, that one TimeTariffInterval will 8040 link to a ConsumptionTariffIntervalList containing multiple (5, in this example) 8041 ConsumptionTariffInterval resources. 8042
Note that under a block rate design, as opposed to flat or TOU rate designs, a pricing client cannot 8043 determine the active price solely from the pricing server. The client will also have to query the 8044 corresponding metering server to determine which consumption block is active. 8045
17.1.5 Combined Time-of-Use and Consumption-based Block Rate Design 8046
Yet other jurisdictions (e.g., California), have combined time-of-use and consumption-based rate designs 8047 to incentivize efficient consumption as well as shifting that consumption to times of lower system 8048 demand. 8049
For this TOU with consumption-based rate design, assume a tariff structure that combines the previous 8050 two examples as shown in Table 17-3: 8051
Table 17-3 Tariff Structure. 8052
Time Tier Block Consumption startValue Description Price
Midnight – 8 AM 1 1 0 Off-peak $0.22
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 337 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
Time Tier Block Consumption startValue Description Price
2 150 $0.24 3 250 $0.33 4 300 $0.37 5 350 $0.40
8 AM – 10 AM
2 1 0
Mid-peak
$0.32 2 150 $0.34 3 250 $0.43 4 300 $0.47 5 350 $0.50
10 AM – 6 PM
3 1 0
On-peak
$0.52 2 150 $0.54 3 250 $0.73 4 300 $0.77 5 350 $0.80
6 PM - Midnight
2 1 0
Mid-peak
$0.32 2 150 $0.34 3 250 $0.43 4 300 $0.47 5 350 $0.50
Intermittent
4 1 0
CPP
$0.82 2 150 $0.84 3 250 $0.93 4 300 $0.97 5 350 $1.00
Using the above TOU+Block example, the tariff's RateComponent must link to a ReadingType with the 8053 following attributes: 8054
� numberOfConsumptionBlocks = 5 8055
� numberOfTouTiers = 4 8056
Continuing the above example, consider a pricing server configured as follows: 8057
� Server provides 48 hours of price information. 8058
� Price information is updated every midnight. 8059
� The local time is 9 AM on July 16, 2012. 8060
� There is a CPP event scheduled for 1 PM – 3 PM on July 16, 2012. 8061
In this scenario, the server's TimeTariffIntervalList will contain 10 TimeTariffIntervals: 8062
1) One expired event (Tier 1, present day 00:00:00 – 08:00:00) 8063
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 338 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
2) One active event (Tier 2, present day 08:00:00 – 10:00:00) 8064
3) Eight scheduled events, corresponding to: 8065
1) Tier 3, present day 10:00:00 – 13:00:00 8066
2) Tier 4 (CPP), present day 13:00:00 – 15:00:00 8067
3) Tier 3, present day 15:00:00 – 18:00:00 8068
4) Tier 2, present day 18:00:00 – next day 00:00:00 8069
5) Tier 1, next day 00:00:00 – 08:00:00 8070
6) Tier 2, next day 08:00:00 – 10:00:00 8071
7) Tier 3, next day 10:00:00 – 18:00:00 8072
8) Tier 2, next day 18:00:00 – day after next 00:00:00 8073
Each TimeTariffInterval links to its own ConsumptionTariffIntervalList, and each 8074 ConsumptionTariffIntervalList will contain 5 ConsumptionTariffInterval resources with 8075 consumptionBlock, startValue, and price attributes set per the above TOU+Block rate. 8076
As with the block rate design, under a TOU+Block design a pricing client cannot determine the active 8077 price solely from the pricing server; the client must determine the active block from the associated 8078 metering server. 8079
17.1.6 Coordinated and Uncoordinated Pricing and Metering Servers 8080
As with all function set servers in SEP 2, Pricing and Metering servers may be hosted by different service 8081 providers, served by the same provider on separate hosts, or coordinated or uncoordinated depending on 8082 the rules of the jurisdiction. This is problematic for certain tariff designs, particularly for consumption-8083 based tariffs, which depend on usage accumulated during a given billing period in order to be able to 8084 provide accurate Pricing information. For example, in Texas, the Retail Energy Provider (REP) owns the 8085 customer relationship and is responsible for serving Pricing information, but the Transmission 8086 Distribution Service Provider (TDSP) owns the meter and provides one standard meter configuration for 8087 all users, regardless of the REP, which may change depending on the customer's preferences. Another use 8088 case is a customer who may not have a smart meter but installs his own and links his HAN to his 8089 electricity service provider's Pricing server on its website. 8090
This section recommends mitigation strategies and coping mechanisms to help Pricing and Metering 8091 clients provide users with actionable information to make informed decisions in the event that the 8092 ReadingType instance referenced by the Pricing server does not match any of the Metering server 8093 implementations available in the HAN. Devices that follow Pricing servers primarily for price 8094 responsiveness (e.g., smart appliances) do not need to follow these recommendations because the 8095 numberOfTouTiers and touTier attributes in the pricing server's ReadingType and TimeTariffInterval 8096 resources provide the guidance needed to optimize operational parameters. 8097
The following rules are recommended for clients of Pricing and Metering resources and which aim to 8098 present a user with cost information about their usage or determine a nominal price for energy. These 8099 rules presume a client has performed service discovery and identified a suitable Metering server for its 8100 application (e.g., the premises aggregation point, PEV sub-meter). The first three rules assume that the 8101 Pricing and Metering servers are coordinated. Rules four and five are meant to guide implementations in 8102 scenarios where the Pricing and Metering servers are uncoordinated. 8103
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.
Smart Energy Profile 2, 13-0200-00, April 2013 Smart Energy Profile 2
Page 339 Copyright © 2013, ZigBee Alliance, Inc. and HomePlug Powerline Alliance, Inc. All rights reserved.
1) Metering servers SHOULD, at a minimum, serve a ReadingType instance for commodity 8104 delivered summation. This provides a functionality baseline that all devices can expect to be 8105 available in a HAN. 8106
2) If Rule #1 is not satisfied, and if the ReadingTypeLink URI in the Pricing server's 8107 RateComponent object and the Metering server's MeterReading object are the same, then they are 8108 a match. 8109
3) If Rule #2 is not satisfied, then the client SHOULD refer to the MeterReading instances' mRID 8110 attributes. If the Pricing and Metering servers' MeterReading.mRID attributes are the same, then 8111 they are a match. 8112
4) If Rule #3 is not satisfied, then the client should compare values in order to find the best fit. 8113
a) The following attributes SHALL be exact matches in both servers' ReadingType 8114 instances: 8115
� commodity 8116
� flowDirection 8117
� kind 8118
� uom 8119
b) The following attributes SHOULD match in both servers' ReadingType instances or be 8120 accounted for (e.g., accumulationBehaviour attribute in Pricing server may be "Delta 8121 Data" whereas the Metering server may only provide "Cumulative"; these can be matched 8122 with the appropriate device logic) or have at least one be designated as "Not Specified": 8123
� accumulationBehaviour 8124
� phase 8125
5) If Rule #4 is not satisfied, clients SHOULD NOT display cost information to the user. Pricing 8126 clients SHOULD only display Pricing information. Pricing clients may indicate a mismatch 8127 between the Pricing and Metering server information and provide guidance to the user to contact 8128 his installer or service provider. 8129
17.2 PEV Implementation Guidelines (subject to work with SAE and ISO / IEC) 8130
Plug-In Electric Vehicles (PEVs) should implement Registration, DRLC, Pricing, and Messaging in order 8131 to alert the user of upcoming program events and to avoid charging during peak times. They may also 8132 implement FlowReservation in order to provide the ability to avoid high aggregated demand across 8133 multiple PEVs. They may also implement DER functionality in order to participate in programs that send 8134 advanced controls for grid conditioning and generation. Electric Vehicle Service Equipment (EVSE) may 8135 also use these functions, and may also use or implement metering to publish or obtain readings from 8136 another device in order to manage charging functions. 8137
Authorized licensed use limited to: ERNET INDIA. Downloaded on February 07,2014 at 18:43:21 UTC from IEEE Xplore. Restrictions apply.