energy interoperation version 1...william cox 5/11/11 1:20 am deleted: march 3 william cox 5/11/11...

energyinterop-v1-0-wd23 Working Draft May 10 2011 Copyright © OASIS® 2011. All Rights Reserved. Standards Track Work Product of 79

William Cox� 5/11/11 1:20 AMDeleted: March 3

William Cox� 5/11/11 1:20 AMDeleted: 2010.

Energy Interoperation Version 1.0

Working Draft 23

10 May 2011

Abstract: Energy interoperation describes an information model and a communication model to enable collaborative and transactive use of energy, service definitions consistent with the OASIS SOA Reference Model [SOA-RM], and XML vocabularies for the interoperable and standard exchange of:

• Dynamic price signals • Reliability signals • Emergency signals • Communication of market participation information such as bids • Load predictability and generation information

This work facilitates enterprise interaction with energy markets, which: • Allows effective response to emergency and reliability events • Allows taking advantage of lower energy costs by deferring or accelerating usage, • Enables trading of curtailment and generation, • Supports symmetry of interaction between providers and consumers of energy, • Provides for aggregation of provision, curtailment, and use,

The definition of a price and of reliability information depends on the market context in which it exists. It is not in scope for this TC to define specifications for markets or for pricing models, but the TC has coordinated with others to ensure that commonly used market and pricing models are supported. While this specification uses Web Services to describe the services, no requirement or expectation of specific messaging implementation is assumed.

Status: This document is a Working Draft and as such has no official standing with regard to the OASIS Technical Committee Process.

Copyright © OASIS® 2011. All Rights Reserved. All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

William Cox� 5/11/11 1:20 AMDeleted: 04

William Cox� 5/11/11 1:20 AMDeleted: will coordinate

energyinterop-v1-0-wd23 Working Draft May 10, 2011 Copyright © OASIS® 2011. All Rights Reserved. Standards Track Work Product of 79


Table of Contents 1 Introduction ............................................................................................................................................ 7

1.1 Terminology ....................................................................................................................................... 8 1.2 Normative References ....................................................................................................................... 8 1.3 Non-Normative References ............................................................................................................... 8 1.4 Contributions ................................................................................................................................... 10 1.5 Namespace ..................................................................................................................................... 11 1.6 Naming Conventions ....................................................................................................................... 11 1.7 Editing Conventions ......................................................................................................................... 11 1.8 Architectural Background ................................................................................................................ 12

2 Overview of Energy Interoperation ...................................................................................................... 13 2.1 Scope of Energy Interoperation ....................................................................................................... 13 2.2 Specific scope statements ............................................................................................................... 13 2.3 Goals & Guidelines for Signals and Price and Product Communication ......................................... 13 2.4 Scope of Energy Interoperation Communications ........................................................................... 14 2.5 Smart Energy [Not Normative] ......................................................................................................... 14 2.6 Assumptions .................................................................................................................................... 16

2.6.1 Availability of Interval Metering ................................................................................................ 16 2.6.2 Use of EMIX ............................................................................................................................. 16 2.6.3 Use of WS-Calendar ................................................................................................................ 16 2.6.4 Energy Services Interface ........................................................................................................ 16

3 Energy Interoperation Architecture ...................................................................................................... 17 3.1 Transactive Energy Interactions ...................................................................................................... 17

3.1.1 Buyer and Seller Party Roles ................................................................................................... 17 3.1.2 Transactive Interactions and Roles .......................................................................................... 17 3.1.3 Retail Service Interactions ....................................................................................................... 18 3.1.4 Wholesale Power Interactions .................................................................................................. 18 3.1.5 Transport Interactions .............................................................................................................. 18

3.2 Event Interactions for Demand and Generation Resources ............................................................ 19 3.2.1 VTN and VEN Party Roles ....................................................................................................... 19 3.2.2 VTN/VEN Interactions .............................................................................................................. 19 3.2.3 VTN/VEN Roles and Services .................................................................................................. 21 3.2.4 Demand Response Interactions ............................................................................................... 22

4 Message Composition & Services ....................................................................................................... 23 4.1 WS-Calendar in Energy Interoperation ............................................................................................ 23

4.1.1 Simple Sequences in WS-Calendar ......................................................................................... 23 4.2 EMIX and Energy Interop ................................................................................................................ 24 4.3 Using Gluons to Define Transactions .............................................................................................. 25 4.4 Applying EMIX and WS-Calendar to a Power Event ....................................................................... 26

5 Introduction to Services and Operations ............................................................................................. 27 5.1 Describing Services and Operations ............................................................................................... 27 5.2 Resources, Curtailment, and Generation ........................................................................................ 27 5.3 Structure of Energy Interoperation Services and Operations .......................................................... 27 5.4 Naming of Services and Operations ................................................................................................ 28

William Cox� 5/11/11 1:20 AMDeleted: 1.1 Terminology 8 ... [1]



5.5 Push and Pull Patterns .................................................................................................................... 28 5.6 Description of the Services and Operations .................................................................................... 28

6 Transactive Services ........................................................................................................................... 29 6.1 EiRegisterParty Service ................................................................................................................... 29

6.1.1 Interaction Pattern for the EiRegisterParty Service .................................................................. 29 6.1.2 Information Model for the EiRegisterParty Service .................................................................. 30 6.1.3 Operation Payloads for the EiRegisterParty Service ............................................................... 31

6.2 Pre-Transaction Services ................................................................................................................ 31 6.2.1 Interaction Pattern for the EiTender and EiQuote Services ..................................................... 32 6.2.2 Information Model for the EiTender and EiQuote Services ...................................................... 34 6.2.3 Operation Payloads for the EiTender Service .......................................................................... 35 6.2.4 Operation Payloads for the EiQuote Service ........................................................................... 36

6.3 Transaction Management Services ................................................................................................. 36 6.3.1 Interaction Patterns for the EiTransaction Service ................................................................... 37 6.3.2 Information Model for the EiTransaction Service ..................................................................... 37 6.3.3 Operation Payloads for the EiTransaction Service .................................................................. 38

6.4 Post-Transaction Services ............................................................................................................... 38 6.4.1 Energy Delivery Information ..................................................................................................... 38 6.4.2 Full Requirements Verification ................................................................................................. 39

7 Enroll Service ...................................................................................................................................... 40 7.1 Interaction Patterns for the EiEnroll Service .................................................................................... 41 7.2 Information Model for the EiEnroll Service ...................................................................................... 42 7.3 Operation Payloads for the EiEnroll Service ................................................................................... 43

8 Event Services ..................................................................................................................................... 44 8.1 EiEvent Service ............................................................................................................................... 44

8.1.1 Interaction Patterns for the EiEvent Service ............................................................................ 44 8.1.2 Information Model for the EiEvent Service ............................................................................... 45 8.1.3 Operation Payloads for the EiEvent Service ............................................................................ 47

8.2 Feedback Service ............................................................................................................................ 48 8.2.1 Interaction Pattern for the EiFeedback Service ........................................................................ 48 8.2.2 Information Model for the EiFeedback Service ........................................................................ 49 8.2.3 Operation Payloads for the EiFeedback Service ..................................................................... 50

8.3 EiProgram Service ........................................................................................................................... 51 8.3.1 Interaction Patterns for the EiProgram Service ........................................................................ 52 8.3.2 Information Model for the EiProgram Service .......................................................................... 54 8.3.3 Operation Payloads for the EiProgram Service ....................................................................... 55

9 Support Services ................................................................................................................................. 56 9.1 EiConstraint Service ........................................................................................................................ 56

9.1.1 Interaction Patterns for the EiConstraint Service ..................................................................... 57 9.1.2 Information Model for the EiConstraint Service ........................................................................ 58 9.1.3 Operation Payloads for the EiConstraint Service ..................................................................... 59

9.2 Opt Service ...................................................................................................................................... 59 9.2.1 Interaction Patterns for the EiOpt Service ................................................................................ 60 9.2.2 Information Model for the EiOpt Service .................................................................................. 61 9.2.3 Operation Payloads for the Opt Out Service ............................................................................ 62



9.3 Status Service ................................................................................................................................. 63 9.3.1 Interaction Patterns for the EiStatus Service ........................................................................... 63 9.3.2 Information Model for the EiStatus Service .............................................................................. 63 9.3.3 Operation Payloads for the Status Service .............................................................................. 64

10 Security and Composition [Non-Normative] ...................................................................................... 65 10.1 Security and Reliability Example ................................................................................................... 65 10.2 Composition ................................................................................................................................... 66 10.3 Energy Interoperation and Security ............................................................................................... 67

11 Profiles [Normative] ........................................................................................................................... 68 11.1 OpenADR [Normative] ................................................................................................................... 68 11.2 TEMIX [Normative] ........................................................................................................................ 69 11.3 Price Distribution [Normative] ........................................................................................................ 69

12 Conformance ..................................................................................................................................... 70 A. Background and Development history ............................................................................................... 71 B. Glossary ............................................................................................................................................. 73 C. Extensibility in Energy Interoperation ................................................................................................. 74

C.1 Extensibility in Enumerated values ................................................................................................. 74 C.2 Extension of Structured Information Collective Items ..................................................................... 74

D. Acknowledgements ............................................................................................................................ 76 E. Revision History ................................................................................................................................. 78



Tables, Figures & Examples

Index to Figures Figure 1-1: Conceptual model for smart Grid from [NIST] showing communications requirements ........... 7 Figure 3-1: Parties Interacting with Offers and Transactions as Either Buyers or Sellers. ........................ 18 Figure 3-2: Example DR Interaction One ................................................................................................... 19 Figure 3-3 Example DR Interaction Two .................................................................................................... 20 Figure 3-4: Example DR Interaction Three ................................................................................................ 20 Figure 3-5: Web of Example DR Interactions ............................................................................................ 20 Figure 3-6: Service Interactions between a VTN and a VEN ..................................................................... 21 Figure 3-7: Demand Response Interaction Pattern Example .................................................................... 22 Figure 4-1: Basic Power Object from EMIX ............................................................................................... 23 Figure 4-2: WS-Calendar Partition, a simple sequence of 5 intervals ....................................................... 24 Figure 4-3: Applying Basic Power to a Sequence ..................................................................................... 24 Figure 4-4: Simplifying back to Power in a Single Interval ......................................................................... 24 Figure 4-5: Ramp Rate Curve—CIM Style ................................................................................................ 25 Figure 4-6: Schematic of Use of EMIX and WS-Calendar to describe Power Transaction ....................... 25 Figure 4-7: A Demand Response Market Schematic NEEDS UPDATE ................................................... 26 Figure 6-1 Interaction Diagram for EiRegister Service .............................................................................. 30 Figure 6-2: EiParty UML Class Diagram .................................................................................................... 31 Figure 6-3: UML Class Diagram for EiRegisterParty Service Operation Payloads ................................... 31 Figure 6-4 Interaction Diagram for the EiTender Service .......................................................................... 33 Figure 6-5 Interaction Diagram for the EiQuote Service ............................................................................ 34 Figure 6-6: UML Class Diagram for the Operation Payloads for the EiTender Service ............................. 35 Figure 6-7: UML Class Diagram for the EiQuote Service Operation Payloads ......................................... 36 Figure 6-8 Interaction Diagram for the EiTransaction Service ................................................................... 37 Figure 6-9: UML Class Diagram of EiTransaction Service Operation Payloads ........................................ 38 Figure 7-1 Interaction Diagram for the EiEnroll Service ............................................................................ 42 Figure 8-1 Interaction Pattern for the EiEvent Service .............................................................................. 45 Figure 8-2: UML Class Diagram for the EiEvent and Associated Classes ................................................ 46 Figure 8-3: UML Class Diagram for EiEvent Service Operation Payloads ................................................ 47 Figure 8-4 Interaction Diagram for the EiFeedback Service ...................................................................... 49 Figure 8-5: UML Class Diagram for the EiFeedback Class ....................................................................... 49 Figure 8-6: UML Class Diagram for EiFeedback service operations ......................................................... 50 Figure 8-7: UML Class Diagram for EiFeedback Service Operation Payloads ......................................... 51 Figure 8-8 Interaction Diagram for the EiProgram Service NOTE NAME IS CHANGING ......................... 53 Figure 8-9: UML Class Diagram for the EiProgram Class ......................................................................... 54 Figure 8-10: UML Class Diagram for EiProgram Service Operation Payloads ......................................... 55 Figure 9-1 Interaction Pattern for the EiConstraint Service ....................................................................... 57 Figure 9-2: UML Class Diagram for the EiConstraint and Associated Classes ......................................... 58 Figure 9-3: UML Class Diagram for EiConstraint Service Operation Payloads ......................................... 59

William Cox� 5/11/11 1:20 AMDeleted: Figure 2-1: Conceptual model for smart Grid from [NIST] showing communications requirements 7 ... [2]



Figure 9-4 Interaction Diagram for the EiOpt Service ................................................................................ 60 Figure 9-5: UML Class Diagram for the EiOpt Class ................................................................................. 61 Figure 9-6: UML Class Diagram for EiOptout Service Operation Payloads .............................................. 62 Figure 9-7 Interaction Pattern for the EiStatus Service ............................................................................. 63 Figure 9-8: UML Class Diagram for the EiStatus Class ............................................................................. 64 Figure 9-9: UML Class Diagram for EiStatus Service Operation Payloads ............................................... 64 Figure 10-1: Web of Example DR Interactions .......................................................................................... 65

Index to Tables Table 1-1: Namespaces Used in this Specification ................................................................................... 11 Table 3—1: Interactions and Actors .......................................................................................................... 20 Table 6—1: Register Services ................................................................................................................... 29 Table 6—2: Pre-Transaction Tender Services .......................................................................................... 32 Table 6—3: Pre-Transaction Quote Services ............................................................................................ 32 Table 6—4: Transaction Management Services ........................................................................................ 36 Table 6—5: Energy Usage Information ..................................................................................................... 38 Table 7—1 Enrolling Entity Descriptions ................................................................................................... 40 Table 7—2: EiEnroll Service Operations ................................................................................................... 41 Table 8—1: Event Services ....................................................................................................................... 44 Table 8—2: Feedback Service .................................................................................................................. 48 Table 8—3: EiProgram Service ................................................................................................................. 52 Table 9—1: Constraint Service .................................................................................................................. 56 Table 9—2: Opt-Out Service ..................................................................................................................... 60 Table 9—3: Status Services ...................................................................................................................... 63 Table 10—1: Interactions and Actors for Security and Reliability Example ............................................... 66

William Cox� 5/11/11 1:20 AMDeleted: Table 8—2: Pre-Transaction Tender Services 32 ... [3]

William Cox� 5/11/11 1:20 AMDeleted: Section Break (Next Page)... [4]



1 Introduction 1

Energy Interoperation defines information exchanges and services to coordinate energy supply, 2 transmission, distribution, and use, including power and ancillary services, between any two parties, such 3 as energy suppliers and customers, markets and service providers, in any of the domains indicated in 4 Figure 2.1 below. Energy Interoperation makes no assumptions about which entities will enter those 5 markets, or as to what those market roles will be called in the future. Energy Interoperation supports each 6 of the secure communications interfaces in Figure 2-1, but is not limited to those interfaces. 7

8 Figure 1-1: Conceptual model for smart Grid from [NIST] showing communications requirements 9

Energy Interoperation defines messages to communicate price, reliability, and emergency conditions over 10 communications interfaces. Energy Interoperation is agnostic as to the technology that a communications 11 interface may use to carry these messages. 12 Energy Interoperation messages can concern real time interactions, forward projections, or historical 13 reporting. Energy Interoperation is intended to support market-based balancing of energy supply and 14 demand while increasing fluidity of transactions. Increased deployment of distributed and intermittent 15 energy sources will require greater fluidity in both wholesale and retail markets. In retail markets, Energy 16 Interoperation is meant to support greater consumer choice as to energy source. 17 Energy supplies are becoming more volatile due to the introduction of renewable energy sources. The 18 introduction of distributed energy resources may create localized, volatile surpluses and shortages. These 19 changes will create more granular energy transactions, more granular in temporal changes in price, and 20 more granular in territory. 21 Balancing local energy resources brings more kinds of resources into the mix. Natural gas markets share 22 many characteristics with electricity markets. Local thermal energy distribution systems can balance 23 electricity markets while having their own surpluses and shortages. Nothing in Energy Interoperation 24 restricts its use to electricity-based markets. 25 Energy consumers will need technologies to manage their local energy supply, including curtailment, 26 storage, generation, and time-of-use load shaping and shifting. In particular, consumers will respond to 27 Energy Interoperation messages for emergency and reliability events, or price messages to take 28 advantage of lower energy costs by deferring or accelerating usage, and to trade curtailment, local 29 generation and energy supply rights. Energy Interoperation does not specify which technologies 30 consumers will use; rather it defines a technology agnostic interface to enable accelerated market 31 development of such technologies. 32

William Cox� 5/11/11 1:20 AMFormatted: Font color: CustomColor(RGB(59,0,111))William Cox� 5/11/11 1:20 AMFormatted: Heading 1,Heading 1 Char1Char,Heading 1 Char Char CharChar,Heading 1 Char1 Char Char,Heading1 Char Char CharWilliam Cox� 5/11/11 1:20 AMDeleted: each33



To balance supply and demand, energy suppliers must be able to schedule resources, manage 34 aggregation, and communicate both the scarcity and surplus of energy supply over time. Suppliers will 35 use Energy Interoperation to inform customers of emergency and reliability events, to trade curtailment 36 and supply of energy, and to provide intermediation services including aggregation of provision, 37 curtailment, and use. 38 Energy Interoperation relies on standard format for communication of time and interval [WS-Calendar] 39 and for Energy Price and Product Definition [EMIX]. This document assumes that there is a high degree 40 of symmetry of interaction at any Energy Interoperation interface, i.e., that providers and customers may 41 reverse roles during any period. 42 The OASIS Energy Interoperation Technical Committee is developing this specification in support of the 43 National Institute of Standards and Technology (NIST) Framework and Roadmap for Smart Grid 44 Interoperability Standards, Release 1.0 [Framework] in support of the US Department of Energy (DOE) as 45 described in the Energy Independence and Security Act of 2007 [EISA2007]. 46 Under the Framework and Roadmap, the North American Energy Standards Board (NAESB) surveyed 47 the electricity industry and prepared a consensus statement of requirements and vocabulary. This work 48 was submitted to the Energy Interoperation Committee in April 2010 and subsequently updated and 49 delivered [FIX THIS by means of the ISO-RTO Council requirements] [in 2011]. 50 All examples and all Appendices are non-normative. 51

1.1 Terminology 52

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD 53 NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described 54 in [RFC2119]. 55

1.2 Normative References 56

Alphabetize 57 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, 58

http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997. 59 [RFC2246] T. Dierks, C. Allen Transport Layer Security (TLS) Protocol Version 1.0, 60

http://www.ietf.org/rfc/rfc2246.txt, IETF RFC 2246, January 1999. 61 [SOA-RM] OASIS Standard, Reference Model for Service Oriented Architecture 1.0, 62

October 2006. http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf 63 [EMIX] OASIS Committee Specification Draft 01, Energy Market Information Exchange 64

1.0, November 2010. http://docs.oasis-open.org/emix/emix/v1.0/csd01/emix-v1.0-65 csd01.pdf 66

[WS-Calendar] OASIS Committee Specification Draft, WS-Calendar 1.0, September 2010. 67 http://docs.oasis-open.org/ws-calendar/ws-calendar/v1.0/CD01/ws-calendar-1.0-68 spec-cd-01.pdf 69

1.3 Non-Normative References 70

Alphabetize 71 [OpenADR] Mary Ann Piette, Girish Ghatikar, Sila Kiliccote, Ed Koch, Dan Hennage, Peter 72

Palensky, and Charles McParland. 2009. Open Automated Demand Response 73 Communications Specification (Version 1.0). California Energy Commission, 74 PIER Program. CEC-500-2009-063. 75

[BACnet/WS] Addendum C to ANSI/ASHRAE Standard 135-2004, BACnet Web Services 76 Interface. 77

[ebXML-MS] OASIS Standard, Electronic Business XML (ebXML) Message Service 78 Specification v3.0: Part 1, Core Features, October 2007. http://docs.oasis-79 open.org/ebxml-msg/ebms/v3.0/core/os/ebms_core-3.0-spec-os.pdf 80

William Cox� 5/11/11 1:20 AMDeleted: .81

William Cox� 5/11/11 1:20 AMFormatted: Font:Bold



[EISA2007] Energy Independence and Security Act of 2007, 82 http://nist.gov/smartgrid/upload/EISA-Energy-bill-110-140-TITLE-XIII.pdf 83

[EPRI] Concepts to Enable Advancement of Distributed Energy Resources, 84 February 2010, 85 http://my.epri.com/portal/server.pt?Abstract_id=000000000001020432 86

[Framework] National Institute of Standards and Technology, NIST Framework and Roadmap 87 for Smart Grid Interoperability Standards, Release 1.0, January 2010, 88 http://nist.gov/public_affairs/releases/upload/smartgrid_interoperability_final.pdf 89

[Galvin] Galvin Electricity Initiative, Perfect Power, http://www.galvinpower.org/perfect-90 power/what-is-perfect-power 91

[ID-CLOUD] OASIS Identity in the Cloud Technical Committee 92 http://www.oasis-open.org/committees/id-cloud 93

[KMIP] OASIS Standard, Key Management Interoperability Protocol Specification 94 Version 1.0, October 2010 95 http://docs.oasis-open.org/kmip/spec/v1.0/kmip-spec-1.0.pdf 96

[SAML] OASIS Standard, Security Assertion Markup Language 2.0, March 2005. 97 http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf 98

[NAESB-SG] NAESB Smart Grid Subcommittee, 99 http://www.naesb.org/smart_grid_standards_strategies_development.asp 100

[OASIS SCA] OASIS Service Component Architecture Member Section 101 http://www.oasis-opencsa.org/sca 102

[OASIS PMRM] OASIS Privacy Management Reference Model (PMRM) Technical Committee, 103 http://www.oasis-open.org/committees/pmrm 104

[SPML] OASIS Standard, Service Provisioning Markup Language (SPML) v2 - DSML v2 105 Profile, April 2006. http://www.oasis-106 open.org/committees/download.php/17708/pstc-spml-2.0-os.zip 107

[SOA-RA] OASIS Public Review Draft 01, Reference Architecture for Service Oriented 108 Architecture Version 1.0, April 2008 109 http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/soa-ra-pr-01.pdf 110

[TC57CIM] IEC Technical Committee 57 Common Information Model (IEC 61968 and IEC 111 61970, various dates) 112

[TEMIX] OASIS Working Draft, Transactional Energy White Paper, May 2010. 113 http://www.oasis-open.org/committees/download.php/37954/TeMIX-114 20100523.pdf 115

[WS-Addr] Web Services Addressing (WS-Addressing) 1.0, W3C Recommendation, 116 http://www.w3.org/2005/08/addressing. 117

[WSFED] OASIS Standard, Web Services Federation Language (WS-Federation) Version 118 1.2, 01 May 2009 http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-119 federation-1.2-spec-os.doc 120

[WSRM] OASIS Standard, WS-Reliable Messaging 1.1, November 2004. 121 http://docs.oasis-open.org/wsrm/ws-reliability/v1.1/wsrm-ws_reliability-1.1-spec-122 os.pdf 123

[WS-SecureConversation] OASIS Standard, WS-SecureConversation 1.3, March 2007. 124 http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/ws-125 secureconversation-1.3-os.pdf 126

[WS-Security] OASIS Standard, WS-Security 2004 1.1, February 2006. 127 http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-128 SOAPMessageSecurity.pdf 129

[WS-SX] OASIS Web Services Secure Exchange (WS-SX) Technical Committee 130 http://www.oasis-open.org/committees/ws-sx 131

William Cox� 5/11/11 1:20 AMFormatted: Font:Not Bold



[XACML] OASIS Standard, eXtensible Access Control Markup Language 2.0, February 132 2005. http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-133 os.pdf 134

1.4 Contributions 135

The NIST Roadmap for Smart Grid Interoperability Standards described in the [Framework] requested 136 that many standards development organizations (SDOs) and trade associations work together closely in 137 unprecedented ways. An extraordinary number of groups came together and contributed effort, and time, 138 requirements, and documents. Each of these groups further gathered together, repeatedly, to review the 139 work products of this committee and submit detailed comments. These groups contributed large numbers 140 of documents to the Technical Committee. These efforts intersected with this specification in ways almost 141 impossible to unravel, and the committee acknowledges the invaluable works below which are essential 142 to understanding the North American Grid and its operation today, as well as its potential futures. 143 NAESB Smart Grid Standards Development Subcommittee [NAESB-SG]: 144

The following documents are password protected. For information about obtaining access to 145 these documents, please visit www.naesb.org or contact the NAESB office at (713) 356 0060. 146

[NAESB EUI] NAESB REQ Energy Usage Information Model: 147 http://www.naesb.org/member_login_check.asp?doc=req_rat102910_req_2010_148 ap_9d_rec.doc 149

[NAESB EUI] NAESB WEQ Energy Usage Information Model: 150 http://www.naesb.org/member_login_check.asp?doc=weq_rat102910_weq_2010151 _ap_6d_rec.doc 152

The following documents are under development and subject to change. 153 [NAESB PAP 09] Phase Two Requirements Specification for Wholesale Standard DR Signals 154

– for NIST PAP09: 155 http://www.naesb.org/pdf4/weq_2010_ap_6c_rec_101510_clean.doc 156

[NAESB PAP 09] Phase Two Requirements Specification for Retail Standard DR Signals – for 157 NIST PAP09: http://www.naesb.org/pdf4/retail_2010_ap_9c_rec_101510.doc 158

The ISO / RTO Council Smart Grid Standards Project: 159 Information Model – HTML: http://www.isorto.org/atf/cf/%7B5B4E85C6-7EAC-40A0-8DC3-160

003829518EBD%7D/IRC-DR-InformationModel-HTML-161 Condensed_Rev1_20101014.zip 162

Information Model – EAP: http://www.isorto.org/atf/cf/%7B5B4E85C6-7EAC-40A0-8DC3-163 003829518EBD%7D/IRC-DR-InformationModel-EAP-164 Condensed_Rev1_20101014.zip 165

XML Schemas: http://www.isorto.org/atf/cf/%7B5B4E85C6-7EAC-40A0-8DC3-166 003829518EBD%7D/IRC-DR-XML_Schemas_Rev1_20101014.zip 167

Eclipse CIMTool Project: http://www.isorto.org/atf/cf/%7B5B4E85C6-7EAC-40A0-8DC3-168 003829518EBD%7D/IRC-DR-CIMTool-Project-Workspace_Rev1_20101014.zip 169

Interactions - Enrollment and Qualification: http://www.isorto.org/atf/cf/%7B5B4E85C6-7EAC-170 40A0-8DC3-003829518EBD%7D/IRC-DR-Interactions-171 HTML_Enrollment_And_Qualification_Rev1_20101014.zip 172

Interactions - Scheduling and Award Notification: http://www.isorto.org/atf/cf/%7B5B4E85C6-173 7EAC-40A0-8DC3-003829518EBD%7D/IRC-DR-Interactions-174 HTML_Scheduling_And_Award_Notification_Rev1_20101014.zip 175

Interactions - Deployment and Real Time Notifications: 176 http://www.isorto.org/atf/cf/%7B5B4E85C6-7EAC-40A0-8DC3-177 003829518EBD%7D/IRC-DR-Interactions-178 HTML_Deployment_And_RealTime_Communications_Rev1_20101014.zip 179

Interactions - Measurement and Performance: http://www.isorto.org/atf/cf/%7B5B4E85C6-7EAC-180 40A0-8DC3-003829518EBD%7D/IRC-DR-Interactions-181 HTML_Measurement_And_Performance_Rev1_20101014.zip 182

William Cox� 5/11/11 1:20 AMDeleted: :183



Interactions Non-Functional Requirements: http://www.isorto.org/atf/cf/%7B5B4E85C6-7EAC-184 40A0-8DC3-003829518EBD%7D/IRC-DR-Non-185 Functional_Requirements_Rev1_20100930.pdf 186

UCAIug OpenSG OpenADR Task Force: 187 Need definitive and permanent links here 188 189

1.5 Namespace 190

The XML namespace [XML-ns] URI that MUST be used by implementations of this specification is: 191

http://docs.oasis-open.org/ns/energyinterop 192

Dereferencing the above URI will produce the Resource Directory Description Language [RDDL 2.0] 193 document that describes this namespace. 194 Table 1 lists the XML namespaces that are used in this specification. The choice of any namespace prefix 195 is arbitrary and not semantically significant. 196

Table 1-1: Namespaces Used in this Specification 197

Prefix Namespace xs http://www.w3.org/2001/XMLSchema

kml http://www.opengis.net/kml/2.2

xcal http://docs.oasis-open.org/ns/ws-calendar

emix http://docs.oasis-open.org/ns/emix

power http://docs.oasis-open.org/ns/emix/power

resource http://docs.oasis-open.org/ns/emix/power/resource

ei http://docs.oasis-open.org/ns/energyinterop

The normative schemas for EMIX can be found linked from the namespace document that is located at 198 the namespace URI specified above. 199

1.6 Naming Conventions 200

This specification follows some naming conventions for artifacts defined by the specification, as follows: 201 For the names of elements and the names of attributes within XSD files, the names follow the 202 lowerCamelCase convention, with all names starting with a lower case letter. For example, 203

<element name="componentType" type="ei:ComponentType"/> 204

For the names of types within XSD files, the names follow the UpperCamelCase convention with all 205 names starting with a lower case letter prefixed by “type-“. For example, 206

<complexType name="ComponentServiceType"> 207

For the names of intents, the names follow the lowerCamelCase convention, with all names starting with 208 a lower case letter, EXCEPT for cases where the intent represents an established acronym, in which 209 case the entire name is in upper case. 210 An example of an intent that is an acronym is the "SOAP" intent. 211

1.7 Editing Conventions 212

For readability, element names in tables appear as separate words. The actual names are 213 lowerCamelCase, as specified above, and as they appear in the XML schemas. 214

William Cox� 5/11/11 1:20 AMDeleted: lower camelCase215



All elements in the tables not marked as “optional” are mandatory. 216 Information in the “Specification” column of the tables is normative. Information appearing in the note 217 column is explanatory and non-normative. 218 All sections explicitly noted as examples are informational and are not to be considered normative. 219

1.8 Architectural Background 220

Energy Interoperability defines a service-oriented approach to energy interactions. Accordingly, it 221 assumes a certain amount of definitions of roles, names, and interaction patterns. This document relies 222 heavily on roles and interactions as defined in the OASIS Standard Reference Model for Service Oriented 223 Architecture [SOA-RA]. 224 Service orientation focuses on the desired results rather than the requested processes. Service 225 orientation complements loose integration. Service orientation organizes distributed capabilities that may 226 be in different ownership domains. 227 The SOA paradigm concerns itself with visibility, interaction, and effect. Visibility refers to the capacity for 228 those with needs and those with capabilities to be able to see each other. Interaction is the activity of 229 using a capability. A service provides a decision point for any policies and transactions without delving 230 into the process on either side of the interface 231 Services are concerned with the public actions of each interoperating system. Service interactions 232 consider private actions, e.g., those on either side of the interface, to be inherently unknowable by other 233 parties. A service is used without needing to know all the details of its implementation. Services are 234 generally paid for results, not effort. 235 Loose integration using the SOA style assumes careful definition of security requirements between 236 partners. Size of transactions, costs of failure to perform, confidentiality agreements, information 237 stewardship, and even changing regulatory requirements can require similar transactions be expressed 238 within quite different security contexts. It is a feature of the SOA approach that security is composed in to 239 meet the specific and evolving needs of different markets and transactions. Security implementation must 240 be free to evolve over time and to support different needs. Energy Interoperation allows for this 241 composition, without prescribing any particular security implementation. 242 William Cox� 5/11/11 1:20 AM

Deleted: Interop243



2 Overview of Energy Interoperation 244

2.1 Scope of Energy Interoperation 245

Energy Interoperation (EI) supports the following: 246 • Transactive energy markets [TEMIX] 247 • Distribution of dynamic and contract prices 248 • Demand response approaches ranging from dispatch of load resources (with external contractual 249

penalties for non-compliance) to price levels embedded in an event. 250 • Measurement and confirmation of response. 251

EI engages Distributed Energy Resources (DER) while making no assumptions as to their processes or 252 technology. 253 While this specification supports agreements and transactional obligations, this specification offers 254 flexibility of implementation to support specific programs, regional requirements, and goals of the various 255 participants including the utility industry, aggregators, suppliers, and device manufacturers. 256 It is not the intent of the Energy Interoperation Technical Committee to imply that any particular 257 Agreements are endorsed, proposed, or required in order to implement this specification. Energy market 258 operations are beyond the scope of this specification although the interactions that enable management 259 of the actual delivery and acceptance are within scope. Energy Interoperation defines interfaces for use 260 throughout the transport chain of electricity as well as supporting today’s intermediation services and 261 those that may arise tomorrow. 262

2.2 Specific scope statements 263

Interaction patterns and service definitions to support the following are in scope for Energy Interoperation: 264 • Market communications to support transactive energy. (see [TEMIX]) 265 • Specific offerings by end nodes to alter energy use. 266 • Measurement and confirmation of actions taken, including but not limited to curtailment, 267

generation, and storage, including load and usage information, historical, present, and projected. 268 • Notifications requesting performance on transactions offered or executed. 269 • Information models for price and product communication. 270 • Service definitions for Energy Interoperation 271

The following are out of scope for Energy Interoperation: 272 • Requirements specifying the type of agreement, or tariff used by a particular market. 273 • Validation and verification of performance, except for feedback on curtailment and generation. 274 • Communication (e.g. transport method) other than Web services to carry the messages from one 275

point to another. The messages specified in Energy Interoperation can be transmitted via a 276 variety of transports. 277

2.3 Goals & Guidelines for Signals and Price and Product 278 Communication 279

1. There are at least four market types, and signals and price and product standardization must 280 support all four, while allowing for the key differences that exist and will continue to exist in them. 281 The four market types are: 282 • no open wholesale and no retail competition 283

William Cox� 5/11/11 1:20 AMDeleted: transactive284 William Cox� 5/11/11 1:20 AM

Deleted: ]. EI also supports demand285 William Cox� 5/11/11 1:20 AM

Deleted: limited direct286 William Cox� 5/11/11 1:20 AM

Deleted: control287 William Cox� 5/11/11 1:20 AM

Deleted: override-able suggestions to 288 customers. EI includes measurement and 289 verification of curtailment. 290


William Cox� 5/11/11 1:20 AMMoved (insertion) [1]William Cox� 5/11/11 1:20 AMFormatted: Heading 2,H2,H2 Char

William Cox� 5/11/11 1:20 AMMoved (insertion) [2]




• open wholesale market only 291 • open retail competition only 292 • open wholesale and open retail competition. 293

2. Wholesale market DR signals and price and product communication have different characteristics 294 than retail market DR signals and price and product communication, although Energy 295 Interoperation defines a commonality in format. 296

3. It is likely that most end users, with some exceptions among Commercial and Industrial (C&I) 297 customers, will not interact directly with wholesale market. 298

4. Retail pricing models are complex, due to the numerous tariff rate structures that exist in both 299 regulated and un-regulated markets. Attempts to standardize DR control and pricing signals must 300 not hinder regulatory changes or market innovations when it comes to future tariff or pricing 301 models. 302

5. New business entities such as Energy Service Providers (ESP), Demand Response Providers 303 (DRP), DR Aggregators, and Energy Information Service Providers (EISP), will play an increasing 304 role in DR implementation. Energy Interoperation supports these and new as yet unnamed 305 intermediation services. 306

6. DER may play an increasingly important role in DR, yet the development of tariff and/or pricing 307 models that support DER’s role in DR are still in early stages of development. 308

7. The Customer’s perspective and ability to react to DR control and pricing signals must be a key 309 driver during the development of standards to support DR programs. 310

In addition, it is the policy of the Energy Interoperation Technical Committee that 311 8. Where feasible, customer interfaces and the presentation of energy information to the customer 312

should be left in the hands of the market, systems, and product developers enabled by these 313 specifications. 314

The NAESB Smart Grid Committee [NAESB-SG] provided guidance on the Demand Response and 315 the electricity market customer interactions, as a required input under NIST Smart Grid Priority Action 316 Plan 9 (PAP09). Energy Interoperation relied on this guidance. The service and class definitions, 317 relied on the information developed to support the NAESB effort in the wholesale [IRC] and retail 318 [OpenSG] markets. 319

2.4 Scope of Energy Interoperation Communications 320

While the bulk of examples describe the purchase of real power, emerging energy markets must 321 exchange economic information about other time-sensitive services. 322 For example, delivery of power is often constrained by delivery bottlenecks. The emergence of distributed 323 generation and Plugin Electric Vehicles (PEV) will exacerbate this problem. EMIX includes product 324 definitions for tradable congestion charges and transmission rights. Locational market prices in 325 distribution may come to mirror those already seen in transmission markets. 326 Other services address the direct effects of distribution congestion, including phase imbalances, voltage 327 violations, overloads, etc. 328 These markets introduce different market products, yet the roles and interactions remain the same. 329 Intelligent distribution elements, up to an intelligent transformer take roles in these interactions. 330 A description of the tariffs or market rules to support these interactions is outside the scope of this 331 specification. The interactions patterns were developed to support them in markets in which they are 332 required. 333

2.5 Smart Energy [Not Normative] 334

We consider Smart Energy to be the transactions and management of energy using collaborative 335 approaches, including but not limited to markets, requests for decrease of net demand, while addressing 336 the business goals of the respective parties in arms-length interactions. 337

William Cox� 5/11/11 1:20 AMDeleted: ESIP338


William Cox� 5/11/11 1:20 AMDeleted: REFERENCE339


William Cox� 5/11/11 1:20 AMDeleted: DR340

William Cox� 5/11/11 1:20 AMDeleted: especially, 341

William Cox� 5/11/11 1:20 AMDeleted: documents342

William Cox� 5/11/11 1:20 AMMoved (insertion) [4]William Cox� 5/11/11 1:20 AMMoved (insertion) [5]William Cox� 5/11/11 1:20 AMMoved (insertion) [6]William Cox� 5/11/11 1:20 AM

Moved up [1]: <#>Specific scope 343 statements344

William Cox� 5/11/11 1:20 AMDeleted: <#>346 ... [5]

William Cox� 5/11/11 1:20 AMMoved up [2]: <#>Service definitions for 348 Energy Interoperation349

William Cox� 5/11/11 1:20 AMDeleted: <#>validation of curtailment and 351 generation. 352

William Cox� 5/11/11 1:20 AMMoved up [3]: <#>Communication (e.g. 353 transport method) other than Web services to 354 carry the messages from one point to 355 another. The messages specified in Energy 356 Interoperation can be transmitted via a 357 variety of transports.358

William Cox� 5/11/11 1:20 AMDeleted: Background359



360 In this specification we define the information exchanged and the services needed to implement smart 361 energy. 362 363 Today’s markets are not necessarily tomorrow’s. Today’s retail markets have grown up around conflicting 364 market restrictions, tariffs that are contrary to the goals of smart energy, and historical practices that pre-365 date automated metering and e-commerce. Today’s wholesale market applications, designed, built and 366 deployed in the absence of standards, has resulted in little or no interchangeability among vendor 367 products, complex integration techniques, and duplicated product development. The Technical 368 Committee opted to avoid direct engagement with these problems. Energy Interoperation aims for future 369 flexibility while it addresses the problems of today. 370 While the focus today is on on-demand load reduction, on-demand load increase is just as critical for 371 smart energy interactions. Any large component of intermittent energy sources will create temporary 372 surpluses as well as surfeits. Interactions between different smart grids and between smart grids and end 373 nodes must maximize load shifting to reflect changing surpluses or shortages of electricity. 374 Responsibilities and benefits must accrue together to the participants most willing and able to adapt. 375 The Committee, working with the [EMIX] Technical Committee developed a component model of an 376 idealized market for electricity transactions. This model assumes timely automated interval metering and 377 an e-commerce infrastructure. TEMIX describes electricity in this normal market context. This model was 378 explained in the [TEMIX] paper, an approved work product of the EMIX committee. Using the 379 components in this model, the authors were then able to go back and simulate the market operations of 380 today. 381 Energy Interoperation supports four essential market activities: 382

1. There is an indication of interest (trying to find tenders to buy or sell) when a Party is seeking 383 partner Parties for a demand response transaction or for an energy source or sale. 384

2. There is a tender (offer or bid) to buy or sell a service, e.g. production of energy or curtailment of 385 use. 386

3. There is an execution of a transaction to purchase or supply, generally caused by the 387 acceptance of a tender. 388

4. For some transactions, such as Demand Response, there may be a call for performance or 389 delivery of the subject of a transaction at the agreed-upon price, time, and place. 390

Version 1.0 of Energy Interoperation does not define the critical fifth market activity, measurement and 391 verification (M&V). A NAESB task force is currently (December 2010) defining the business 392 requirements for M&V. 393 Other business models may combine services in novel ways. An aggregator can publish an indication of 394 interest to buy curtailment at a given price. A business willing to respond would offer an agreement to 395 shed load for a specific price. The aggregator may accept some or all of these offers. The performance in 396 this case could be called at the same time as the tender acceptance or later. 397 Communication of price in transactions is at the core of the Energy Interoperation services. We identify 398 four types of prices: 399

1. Priced Offer: a forward offer to buy or sell a quantity of an energy product for a specified future 400 interval of time, the acceptance of which by a counterparty results in a binding agreement. This 401 includes tariff priced offers where the quantity may be limited only by the service connection and 402 DR prices. 403

2. Ex-Post Price: A price assigned to energy purchased or sold that is calculated or assigned after 404 delivery. Price may be set based on market indices, centralized market clearing, tariff calculation 405 or any other process. 406

3. Priced Indication of Interest: the same as a Priced Offer except that no binding agreement is 407 immediately intended. 408

4. Historical Price: A current price, past transaction price, past offered price, and statistics about 409 historical price such as high and low prices, averages and volatility. 410

William Cox� 5/11/11 1:20 AMFormatted: Font color: BlackWilliam Cox� 5/11/11 1:20 AMFormatted: Normal, Don't adjust spacebetween Latin and Asian text, Don't adjustspace between Asian text and numbersWilliam Cox� 5/11/11 1:20 AMDeleted: resulting411

William Cox� 5/11/11 1:20 AMDeleted: /412

William Cox� 5/11/11 1:20 AMDeleted: )413

William Cox� 5/11/11 1:20 AMFormatted: Highlight

William Cox� 5/11/11 1:20 AMDeleted: in 414

William Cox� 5/11/11 1:20 AMDeleted: all415



5. Price Forecast: A forecast by a party of future prices that are not a Priced Indication of Interest or 416 Priced Offer. The quality of a price forecast will depend on the source and future market 417 conditions 418

A grid pricing service is able to answer the following sorts of questions: 419 1. What is the price of Electricity now? 420 2. What will it be in 5 minutes? 421 3. What price will electricity have for each hour of the day tomorrow? 422 4. What will it be at other times in the future? 423 5. What was the highest price for electricity in the last day? Month? Year? 424 6. What was the lowest price for electricity in the last day? Month? Year? 425 7. What was the high price for the day the last time it was this hot? 426

Each answer carries with it varying degrees of certainty. The prices may be fixed tariffs absolutely locked 427 down. The prices may be fixed tariffs, “unless a DR event is called.” The prices may even represent wild 428 guesses about open markets. With a standardized price service, technology providers can develop 429 solutions to help grid operators and grid customers manage their energy use portfolios. 430 This specification also encompasses Emergency or "Grid Reliability" events. Grid Reliability events 431 require mandatory participation in today’s markets. These events are described as standing pre-executed 432 option agreements. A grid operator need merely call for performance as in any other event. 433

2.6 Assumptions 434

2.6.1 Availability of Interval Metering 435

Energy Interoperation for many actions presumes a capability of interval metering where the interval is 436 smaller than the billing cycle. Interval metering may be required for settlement or operations for 437 measurement and verification of curtailment, distributed energy resources, and for other Energy 438 Interoperation interactions. 439

2.6.2 Use of EMIX 440

This specification uses the OASIS Energy Market Information Exchange [EMIX] to communicate product 441 definitions, quantities, and prices. EMIX provides a succinct way to indicate how prices, quantities, or both 442 vary over time. 443

2.6.3 Use of WS-Calendar 444

This specification uses the OASIS [WS-Calendar] specification to communicate schedules and intervals. 445 WS-Calendar is the standard under the NIST Smart Grid Roadmap for all such communication. 446 WS-Calendar expresses a general approach to communications of sequences and schedules, and their 447 gradual complete instantiation during the transactive process. Despite its name, WS-Calendar does not 448 require that communications use web services. 449

2.6.4 Energy Services Interface 450

The Energy Services Interface (ESI) is the external face of the energy-consuming node. The ESI may be 451 directly on an energy management system in the end node, or it may be mediated by other business 452 systems. The ESI is the point of communication whereby the entities (e.g. utilities, ISOs) that produce and 453 distribute electricity interact with the entities (e.g. facilities and aggregators) that manage the consumption 454 of electricity. An ESI may be in front of one system or several, one building or several, or even in front of 455 a microgrid. 456 This work assumes that there is no direct interaction across the ESI. 457


William Cox� 5/11/11 1:20 AMMoved up [7]: <#>What price will electricity 458 have for each hour of the day tomorrow?459




3 Energy Interoperation Architecture 462

The following sections provide an overview of the interaction structure, and define the roles and actors in 463 electricity markets. Later sections will define the interactions more carefully as services. 464

3.1 Transactive Energy Interactions 465

Transactive energy is market-based energy transactions. It is used today for wholesale energy 466 interoperations—buying and selling of energy, trading options, (and what else?). The use of Energy 467 Interoperation to enable present and future energy markets is described in [TEMIX]. This section reviews 468 the generic roles and interactions of parties involved in energy transactions. 469

3.1.1 Buyer and Seller Party Roles 470

The Energy Interoperation (EI) architecture describes interactions between two or more actors. Actors 471 may perform in a chain of actors and supporting actors. 472 The actor for all EI interactions is a Party. An actor is a Party that can take on a number of roles. This 473 terminology follows common business interaction terminology wherein suppliers sell to intermediaries 474 who may buy transport services and sell to end use customers. 475 A Party can be an end use customer, a generator, a retail service provider, a demand response provider, 476 a marketer, a distribution system operator, a transmission system operator, a system operator such as an 477 ISO or RTO, a microgrid operator, or any party engaging in transactions or supporting transactions for 478 energy. 479 Parties may participate in many interactions concurrently as well as over time. In theory, any Party can 480 transact with any other Party subject to applicable regulatory restrictions. In practice, markets will 481 establish interactions between Parties based on regulation, convenience, economics, credit, network 482 structure, locations, and other factors. 483

3.1.2 Transactive Interactions and Roles 484

A Party can take on two basic roles in transactions: 485 • Buyer and 486 • Seller 487

At any moment, each Party has a position in the market. A Party selling power relative to its current 488 position takes the role of a Seller. A Party buying power relative to its current position takes the role of a 489 Buyer. A generator typically takes the role of a Seller, but can also take on the role of a Buyer. A 490 generator may take the role of a Buyer in order to reduce generation because of a change in generator or 491 market conditions. An end-use customer typically takes the role of a Buyer, but if tendered an attractive 492 price may curtail usage and thereby take the role of a Seller. 493 A distributed generator certainly can take on the roles of buyer and seller. If a distributed generator sells 2 494 MW forward of a given interval, it may later decide to buy back all or a portion of the 2 MW if the price is 495 low enough. A distributed storage device takes on the roles of buyer and seller at different times. 496 Parties taking on the roles of Buyers and Sellers interact both through tenders for transactions and 497 through transactions as illustrated in Figure 3-1. 498

William Cox� 5/11/11 1:20 AMDeleted: This section provides499 William Cox� 5/11/11 1:20 AMDeleted: defines500 William Cox� 5/11/11 1:20 AM

Moved up [4]: <#>Scope of Energy 501 Interoperation Communications502

At initial glance, Power and Load Management 503 Management are simple. Turn on generation. 504 Turn off the lights. The price has just doubled. I 505 won’t turn on any resource for less than $100. 506 Energy interoperation addresses these issues 507 through the repeated use of two other 508 standards, Energy Market Information 509 Exchange (EMIX) and WS-Calendar. 510

William Cox� 5/11/11 1:20 AMFormatted: Heading 2,H2,H2 CharWilliam Cox� 5/11/11 1:20 AMDeleted: The emergence of distributed 512 generation and plugin513

William Cox� 5/11/11 1:20 AMMoved up [5]: Electric Vehicles (PEV) will 560 exacerbate this problem. EMIX includes product 561 definitions for tradable congestion charges and 562 ... [6]

William Cox� 5/11/11 1:20 AMDeleted: These market needs529

William Cox� 5/11/11 1:20 AMMoved up [6]: introduce different market 530 products, yet the roles and interactions remain 531 the same. Intelligent distribution elements, up to 532 an intelligent transformer take roles in these 533 interactions.534 At initial glance, Power and Load Management 535 Management are simple. Turn on generation. 536 Turn off the lights. The price has just doubled. I 537 won’t turn on any resource for less than $100. 538 Energy interoperation addresses these issues 539 through the repeated use of two other 540 standards, Energy Market Information 541 Exchange (EMIX) and WS-Calendar. 542

William Cox� 5/11/11 1:20 AMDeleted: At initial glance, Power and Load 558 Management are simple. Turn on generation. 559 ... [7]

William Cox� 5/11/11 1:20 AMFormatted: Heading 3,H3,H3 CharWilliam Cox� 5/11/11 1:20 AMDeleted: views interoperation as taking place 553 in the context of an interaction554 William Cox� 5/11/11 1:20 AMFormatted: Heading 3,H3,H3 CharWilliam Cox� 5/11/11 1:20 AMDeleted: seller.555 William Cox� 5/11/11 1:20 AMDeleted: buyer.556 William Cox� 5/11/11 1:20 AMDeleted: Figure 2.557



563 Figure 3-1: Parties Interacting with Offers and Transactions as Either Buyers or Sellers. 564

If the Tender is a buy offer by B, then when the Tender is accepted by A, A then becomes the Seller and 565 B the Buyer with respect to the new Transaction. Typically, there is an Agreement among parties that 566 facilitates many transactions under the terms of the enabling Agreement. 567 Two parties can also engage in option transactions. An option is a promise granted by the first Party 568 (Promisor) to the second Party (Promisee) usually for some consideration. The Promisee is granted a 569 right to invoke specific transactions (operations) that the Promisor promises to perform. Demand 570 response, ancillary services, and energy option transactions are forms of options. 571 Any Party may take the role of a Buyer or Seller of a tender for an option transaction. After an offer of an 572 option is executed, one Party takes the role of Promisor and the other takes the role of Promisee. In the 573 case of a demand response (DR) option, the DR Manager is in the Promisee Role and the DR Participant 574 is in the Promisor Role. 575

3.1.3 Retail Service Interactions 576

Retail Customers interact with either tariffed cost-of-service retail providers or competitive retail providers 577 with various service plans. Either way the price of the service must be clearly communicated to the 578 customer. With the introduction of interval metering and dynamic pricing, clear communication of pricing 579 and the purchasing decisions by customers is essential. 580 EI provides services to communicate both the tendered prices by retailers to customers and the purchase 581 transaction by customers. Customers with distributed energy resources (DER) or storage may often be 582 seller to retailer or other parties. Transactions may also include call options on customers by the retailer 583 to reduce deliveries and call options by customers on retailer to provide price insurance. 584

3.1.4 Wholesale Power Interactions 585

Retail Energy Providers, Aggregators, Power Marketers, Brokers, Exchanges, System Operators and 586 Generators all interact in the wholesale market for deliveries on the high voltage transmission grid. 587 Transactions include forward transactions for delivery, near-real time transaction and cash settled futures 588 transactions for hedging risks. 589 EI mirrors the tender and transaction interaction patterns of open forward wholesale power markets. Near 590 real-time wholesale markets for resources provided by independent system operators are also provided 591 for in EI design with work ongoing. 592

3.1.5 Transport Interactions 593

Transmission and Distribution services transport energy from one location to another. Transport is the 594 common term used by EI and EMIX to refer to both Transmission and Distribution. Prices for Transport 595

William Cox� 5/11/11 1:20 AMFormatted: Heading 3,H3,H3 Char

William Cox� 5/11/11 1:20 AMDeleted: in596 William Cox� 5/11/11 1:20 AMDeleted: 597 William Cox� 5/11/11 1:20 AMDeleted: retailor598 William Cox� 5/11/11 1:20 AMFormatted: Heading 3,H3,H3 CharWilliam Cox� 5/11/11 1:20 AMDeleted: in599 William Cox� 5/11/11 1:20 AMDeleted: 600 William Cox� 5/11/11 1:20 AMDeleted: mirror601 William Cox� 5/11/11 1:20 AMDeleted: market602 William Cox� 5/11/11 1:20 AMFormatted: Heading 3,H3,H3 Char



are dynamic and need careful communication. EI models tenders and transactions for Transport products 603 using the same interactions as for Energy products. 604 EI makes no assumptions about how prices for Transport are determined. 605

3.2 Event Interactions for Demand and Generation Resources 606

In partial contrast to the transactive model described above, a common interaction model is based on 607 dispatch of resources by Parties. Resources include both generation resources and curtailment 608 resources. Curtailment resources provide reductions in delivery to a customer from a baseline amount; 609 such resources are typically treated as generation resources, usually in the context of events where 610 shortages may occur. Curtailment resources are also called demand response (DR) resources. For DR 611 resources the determination of the baseline is outside the scope of EI. 612

3.2.1 VTN and VEN Party Roles 613

Similar to the Party interactions of transactive energy, event interactions also have an interoperation 614 model between two or more Actors or Parties. One designated Actor is (for that given interaction) called 615 the Virtual Top Node (VTN) and the remaining one or more actors are called Virtual End Node(s), or 616 VEN(s).1. 617 Parties may participate in many interactions concurrently as well as over time. For example, a particular 618 Actor may participate in multiple Demand Response programs, receive price communication from multiple 619 sources, and may in turn distribute signals to additional sets of Parties. 620 The VTN / VEN Interactions combine and compose multiple sets of pairwise interactions to implement 621 more complex structures. By using simple pairwise interactions, the computational and business 622 complexity for each set of Parties is limited, but the complexity of the overall interaction is not limited. 623

3.2.2 VTN/VEN Interactions 624

In this section, we clarify terminology for roles in VTN/VEN Energy Interoperation interaction patterns. 625 The description and approach is consistent with the Service-Oriented Architecture Reference Model 626 [SOA-RM]. All interactions SHALL be between two or more Parties. The role of a Party as a VTN or VEN 627 only has meaning within the context of a particular service interaction. 628 At this level of description, we ignore the presence of application level acknowledgement of invocations, 629 as that reliable and confirmed delivery would typically be implemented by composition with [WS-RM], 630 [WS-Reliability], [WS-SecureConversation] or a similar mechanism. For similar reasons, an actual 631 deployment would compose the necessary security, e.g., [WS-Security], [SAML], [XACML], or [WS-632 SecureConversation]. See Section 10 for a discussion of compositional security. 633 We also ignore typical push or pull patterns for interactions, which are deferred to later sections. 634

635 Figure 3-2: Example DR Interaction One 636

In Figure 3-2, Party A is the VTN with respect to Party B, which acts as the VEN in this interaction. Party 637 C is not a party to this interaction. 638 Subsequently, as shown in Figure 3-3 Party B may act as the VTN for an interaction with Party C, which 639 is acting as the VEN for interaction two. Party A is not a party to this interaction. 640 1 We are indebted to EPRI for the Virtual End Node term [EPRI]


William Cox� 5/11/11 1:20 AMDeleted: another… a common interaction 661 ... [8]


William Cox� 5/11/11 1:20 AMDeleted: This second model …imilar to the 662 ... [9]

William Cox� 5/11/11 1:20 AMFormatted: Comment ReferenceWilliam Cox� 5/11/11 1:20 AMDeleted: actor…ctor is (for that given 663 ... [10]


William Cox� 5/11/11 1:20 AMDeleted: acknowledgement are…eliable and 664 ... [11]

William Cox� 5/11/11 1:20 AMDeleted: Figure 4,… REF _Ref287163402 \h 665 ... [12]

William Cox� 5/11/11 1:20 AMDeleted: to EPRI, http://my.epri.com/portal/server.pt?Abstract_id=000000000001020432



666 Figure 3-3 Example DR Interaction Two 667

Moreover, the directionality and the roles of the interaction can change as shown in Figure 3-4. Again, 668 Party A is not a party to this interaction, but now Party C is the VTN and Party B is the VEN. 669

670 Figure 3-4: Example DR Interaction Three 671

There is no hierarchy implied by these examples—we are using them to show how the pairwise 672 interaction patterns and the respective roles that entities play can be composed in ways that are limited 673 only by business needs and feasibility, and not by the architecture. From these simple interactions, one 674 can construct more complex interactions such as those shown in Figure 3-5. 675

676 Figure 3-5: Web of Example DR Interactions 677

In this figure, certain Parties (B, E, and G) act as both VTN and VEN. This directed graph with arrows 678 from VTN to its VENs could model a Reliability DR Event initiated by the Independent System Operator2 679 A who would invoke an operation on its second level VTNs B-E, which could be a group of aggregators. 680 The second level VTN B, in turn invokes the same service on its VENs FGH, who may represent their 681 customers or transactional resources. Those customers might be industrial parks with multiple facilities, 682 real estate developments with multiple tenants, or a company headquarters with facilities in many 683 different geographical areas, who would invoke the same operation on their VENs. 684 Each interaction can have its own security and reliability composed as needed—the requirements vary for 685 specific interactions. 686 The following table has sample functional names for selected nodes. 687

Table 3—1: Interactions and Actors 688

Label Structure Role Possible Actor Names

2 Using North American Terminology.

William Cox� 5/11/11 1:20 AMDeleted: transactioned689



A VTN System Operator, DR Event Initiator, Microgrid controller, landlord

B VEN (wrt A), VTN (wrt F, G, H)

Aggregator, microgrid element, tenant, floor, building, factory

G VEN (wrt B), VTN (wrt I, J, L)

Microgrid controller, building, floor, office suite, process controller, machine

L VEN (wrt G and wrt E)

Microgrid element, floor, HVAC unit, machine

3.2.3 VTN/VEN Roles and Services 690

We have defined two structured roles in each interaction, the Virtual Top Node (VTN) and the Virtual End 691 Node (VEN). A VTN has one or more associated VENs.3 692 Considering service interactions for Energy Interoperation, each VTN may invoke services implemented 693 by one or more of its associated VENs, and each VEN may invoke services implemented by its 694 associated VTN. 695 In later sections we detail abstract services that address common transactions, Demand Response, price 696 distribution, and other use cases. 697

698 Figure 3-6: Service Interactions between a VTN and a VEN 699

The interacting pairs can be connected into a more complex structure as we showed in Figure 3-5. 700 The relationship of one or more VENs to a VTN mirrors common configurations where a VTN (say an 701 aggregator) has many VENs (say its transactioned resources) and each VEN works with one VTN for a 702 particular interaction.4 703 Second, as we have seen, each VEN can implement the VTN interface for another interaction. 704 Third, the pattern is recursive as we showed above in Figure 3-5 and allows for more complex structures.5 705

3 The case of a VTN with zero VENs may be theoretically interesting but has little practical value, hence in a later section we formally describe the VENs having cardinality 1..n. 4 The model allows e.g. Demand Resources to participate in more than one interaction, that is, in more than one Demand Response program or offer or with more than one aggregator.




Finally, the Parties of the directed interaction graph can be of varying types or classes. In a Reliability DR 706 Event, a System Operator as a VTN may initiate the event with the service invoked on its next level 707 (highest) VENs, and so forth. But the same picture can be used to describe many other kinds of 708 interaction, e.g. interactions to, from, or within a microgrid [Galvin], price and product definition 709 distribution, or distribution and aggregation of projected load and usage. 710 In some cases the structure graph may permit cycles, in others not. 711

3.2.4 Demand Response Interactions 712

In this section we describe the interaction patterns of the services for demand response respectively 713 invoked by an VTN on one or all of its associated VENs and vice versa. Figure 3-6 above shows the 714 generic interaction pattern; Figure 3-7 below is specific to Demand Response Events. 715 By applying the recursive definitions of VTN and VEN, we will define specific services in the next 716 sections. See Figure 3-7 for service names which are defined more fully in the following sections. 717 The VTN invokes operations on its VENs such as Initiate DR Event and Cancel DR Event, while the VEN 718 invokes operations on its VTN such as Submit DR Standing Bid and Set DR Event Feedback. 719 Note not all DR works this way. A customer may be sent a curtailment tender by the DR provider with a 720 price and then can decide to respond. If the customer has agreed to a capacity payment then there may 721 be a loss of payments if he does not respond, As shown below, standing bids do not require an event 722 notification, only a notification of acceptance. 723

724 Figure 3-7: Demand Response Interaction Pattern Example 725

726

5 For example, [OpenADR1.0] has four actors (the Utility, Demand Response Application Server, the Participant, and the Client (of the Participant). The Energy Interoperation architecture maps clearly to the DRAS-Participant interface, and models the Participant-Client interface as an additional VTN-VEN relationship.




4 Message Composition & Services 727

At a first glance, Power and Load Management are simple. Turn on generation. Turn off the lights. The 728 price has just doubled. I won’t turn on any resource for less than $100. 729 Energy interoperation addresses transactional energy and event interactions through the repeated use of 730 two other standards, Energy Market Information eXchange (EMIX) and WS-Calendar. 731

• EMIX describes price and product for electricity markets. 732 • WS-Calendar communicates schedules and sequences of operations. 733 • Energy Interoperation uses the vocabulary and information models defined by those 734

specifications to describe many of the services and events that it provides. 735

4.1 WS-Calendar in Energy Interoperation 736

WS-Calendar defines how to use the semantics of the enterprise calendar communications standard 737 iCalendar within service communications. 738 WS-Calendar allows for ways to express a related group of time intervals as a sequence. It additionally 739 allows for a way to abstract certain information of related intervals to avoid repetition of such information 740 in every interval of the sequence. This abstraction is called a WS-Calendar Gluon, and it can be related to 741 a group of intervals in a sequence to represent the same common information present in all intervals in a 742 sequence. Gluons can represent interval information such as "duration" that might stay constant over time 743 inside all the intervals in the sequence. Energy Interoperation uses EMIX to describe the energy 744 resources and products that are contained within the WS-Calendar intervals. 745 WS-Calendar is also used directly within Energy Interoperation to specify transactions such as availability 746 and option call windows. For example, generation reserves may make themselves available only on 747 summer afternoons on weekdays. Some tariffs may specify that suppliers may call for performance on 748 Demand Response events only during a fixed schedule which may span times of day over several 749 months. While these schedules can be difficult to communicate unambiguously, they are common in 750 iCalendar; it is a common to schedule a meeting for Mondays and Wednesdays for the next two months. 751 Because WS-Calendar is derived from iCalendar, it is able to express this availability. 752 WS-Calendar Gluons associate with intervals in a sequence and share information with them. Gluons can 753 control the start time and duration of intervals in a sequence. Gluons can contain the same artifacts as do 754 intervals. A complex artifact may be shared between a Gluon and each interval in a sequence, so that 755 invariant information is expressed only once, in the Gluon, and the information that changes over time, 756 perhaps price or quantity, is the only part of the artifact in each interval. 757 Practitioners should read [WS-Calendar] to fully the expressiveness of that specification. 758

4.1.1 Simple Sequences in WS-Calendar 759

Nearly every response, every event, and every interaction in Energy Interoperation can have a payload 760 that varies over time, i.e., it is described using a sequence of intervals. Many communications, particularly 761 in today’s retail market, involve information about or a request for a single interval. Simplicity and 762 parsimony of expression must coexist with complexity and syntactical richness. 763 The simplest power description in EMIX is transactional power. The simplest demand response is to 764 reduce power. The power object in EMIX can include specification of voltage, and Hertz and quality and 765 other features. There are market interactions where each all of those are necessary. Reduced to its 766 simplest, though, the EMIX Power information consists of Power Units and Power Quantity: as in 767

768 Figure 4-1: Basic Power Object from EMIX 769

William Cox� 5/11/11 1:20 AMDeleted: initial770 William Cox� 5/11/11 1:20 AMDeleted: Energy interoperation addresses 771 these issues through the repeated use of two 772 other standards, Energy Market Information 773 Exchange (EMIX) and WS-Calendar. 774 William Cox� 5/11/11 1:20 AM

Deleted: 775 William Cox� 5/11/11 1:20 AM

Deleted: 776 William Cox� 5/11/11 1:20 AMFormatted: List Paragraph, Bulleted +Level: 1 + Aligned at: 0.25" + Indent at: 0.5"William Cox� 5/11/11 1:20 AM

Deleted: these777 William Cox� 5/11/11 1:20 AM

Deleted: Interop778 William Cox� 5/11/11 1:20 AMDeleted: gluon779 William Cox� 5/11/11 1:20 AMDeleted: intervals, but applicable to 780 William Cox� 5/11/11 1:20 AMDeleted: start time" and "781 William Cox� 5/11/11 1:20 AMDeleted: would782 William Cox� 5/11/11 1:20 AMDeleted: Interop783 William Cox� 5/11/11 1:20 AMDeleted: exchange descriptions of784 William Cox� 5/11/11 1:20 AMDeleted: ,785 William Cox� 5/11/11 1:20 AMDeleted: reserve786 William Cox� 5/11/11 1:20 AMDeleted: ..787 William Cox� 5/11/11 1:20 AMDeleted: gluons788 William Cox� 5/11/11 1:20 AMDeleted: Interval789 William Cox� 5/11/11 1:20 AMDeleted: Artifact790



At its simplest, though, WS-Calendar expresses repeating intervals of the same duration, one after the 791 other, and something that changes over the course of the schedule 792

793 Figure 4-2: WS-Calendar Partition, a simple sequence of 5 intervals 794

The WS-Calendar specification defines how to spread an object like the first over the schedule. The 795 information that is true for every interval is expressed once only. The information that changes during 796 each interval, is expressed as part of each interval. 797

798 Figure 4-3: Applying Basic Power to a Sequence 799

Most communications, particularly those in Demand Response, communicate requirements for a single 800 interval. When expressing market information about a single interval, the market object (Power) and the 801 single interval collapse to a simple model: 802

803 Figure 4-4: Simplifying back to Power in a Single Interval 804

In Energy Interoperation, all intervals are expressed using the structure of WS-Calendar. In most 805 interactions, these messages look like Figure 4-4, simple and compact. When an information element is 806 more complex, and varies over time, it may expand as in Figure 4-3. But in all cases, DR Events, Price 807 Quotes, or Program Calls, the essential message is an Information object applied to a WS-Calendar 808 sequence. 809

4.2 EMIX and Energy Interop 810

EMIX provides price and product definitions for electricity markets. EMIX elements are closely aligned 811 with the Market Interfaces as defined in the [CIM]. EMIX specifies Power Options and Power Products by 812 applying Product Descriptions to WS-Calendar Sequences. Product Descriptions are shared as Artifacts 813 across Sequences, with the invariant information expressed only in the Gluon, and the information that 814 changes over time, perhaps price, or quantity, in each interval. 815 EMIX describes Reserves using the language of market Options, whether they are spinning reserves, on 816 call to provide power, or are demand responsive load, ready to reduce use upon request. EMIX Options 817 describe the transaction to stand ready, expressed as a business schedule. EMIX Options defines the 818 potential size of the response that can be called. The EMIX Option includes a warranted response time. 819 Finally, calling the EMIX Option, whether Power or Load, defines a strike price, which is expressed either 820 as an absolute amount or as a price relative to the current market. 821 The EMIX Resource describes a service that could be brought to market. Each Resource may have a lag 822 time before responding. Non-trivial responses may take a while during which the amount of power is 823 ramping up or down. In the IEC TC57 [CIM], these ramp rates are expressed as a Ramp Rate Curve, as 824 shown in Figure 4-5. 825

William Cox� 5/11/11 1:20 AMDeleted: wherein826



827 Figure 4-5: Ramp Rate Curve—CIM Style 828

Resources may also have minimum responses, or maximum run times, or minimum required times 829 between each invocation. 830 By expressing resources in terms of capabilities and ramp rates, a potential purchaser can determine if a 831 resource meets his or her needs, tendering a single resource to a variety of purchase scenarios. 832 Many message payloads in Energy Interoperation consist of the delivery of EMIX objects. The reader who 833 is not familiar with EMIX and its capabilities may have a hard time understanding what message each of 834 the services delivers. 835 The simplest EMIX object, a product with a Gluon to describe it and a Sequence consisting of a single 836 interval containing a single price collapses down to product, time, duration, and price. 837

4.3 Using Gluons to Define Transactions 838

839 Figure 4-6: Schematic of Use of EMIX and WS-Calendar to describe Power Transaction 840

1. Power source defines product to market (Sequence and Gluon 1). 841

William Cox� 5/11/11 1:20 AMDeleted: the 842 William Cox� 5/11/11 1:20 AMDeleted: describing gluon843 William Cox� 5/11/11 1:20 AMDeleted: the sequence844 William Cox� 5/11/11 1:20 AMDeleted: collapse845



2. Product is offered to market on a particular day ([1] and Gluon 2) (Date but not time, required 846 price specified) 847

3. Transaction specifies start time (9:00) and duration (6:30) (Gluon 3), inherited by Sequence 848 through Gluons 2 and 1. Interval B (linked to Gluon 1) is the interval that starts at 9:00. 849

4.4 Applying EMIX and WS-Calendar to a Power Event 850

Consider the event in Figure 4-7: A Demand Response Market Schematic. This event illustrates the 851 potential complexity of marshaling a load response from a VEN, perhaps a commercial building. 852

853 Figure 4-7: A Demand Response Market Schematic NEEDS UPDATE 854

Note first that there are two schedules of prices. The price of electricity for the building “bldg price” is 855 rising to more than double its original price of $0.15 during the interval. The price for Electric Vehicles 856 (EV) is fixed at the lower-than-market rate of $0.12, perhaps because public policy is set to encourage 857 their use. Each of those price curves has an EMIX description. 858 The dispatch level, i.e., the load reduction made by the building, varies over time. This may be tied to 859 building capabilities, or to maintaining essential services for the occupants. It is not important to the VTN 860 why it is constrained, only that it is. Note that these reductions do not line up with the price intervals on 861 the bar above. In this example, the dispatch level is applied to its own WS-Calendar sequence. 862 Before and after the event, there is a notification period and a recovery period, respectively. These are 863 fixed durations communicated from the VEN to the VTN, which then must respect them in transactions it 864 awards the VEN. These durations are expressed in the EMIX Resource Description provided by the VEN, 865 and reflected in the Power Transaction awarded by the VTN. 866

William Cox� 5/11/11 1:20 AMFormatted: Font:Italic

William Cox� 5/11/11 1:20 AMFormatted: HighlightWilliam Cox� 5/11/11 1:20 AMDeleted: Building Price867 William Cox� 5/11/11 1:20 AMDeleted: energy868 William Cox� 5/11/11 1:20 AMDeleted: its own869 William Cox� 5/11/11 1:20 AMDeleted: .870 William Cox� 5/11/11 1:20 AMDeleted: are871



5 Introduction to Services and Operations 872

5.1 Describing Services and Operations 873

In the following sections we describe services and operations consistent with [SOA-RM]. For each 874 service operation there is an actor that invokes the service operation and one that provides the service. 875 We have indicated these roles by the table headings Service Consumer for the actor or role that 876 consumes or invokes the service operation named in the Operation column and Service Provider for the 877 actor or role that provides or implements the service operation as named in the Operation column. 878 We use this terminology through all service definitions in this standard. 879 The column labeled Response Operation lists the name of the service operation invoked as a response. 880 Most operations have a response, excepting primarily those operations that broadcast messages. The 881 roles of Service Consumer and Service Provider are reversed for the Response Operation. 882 All communication between customer devices and energy service providers is through the ESI. 883 For transactive services, the customer will receive tenders (priced offers) of service and possibly make 884 tenders (priced offers) of service. 885

5.2 Resources, Curtailment, and Generation 886

If the VTN participates in a demand response or distributed energy program, each ESI is the interface to 887 at least one dispatchable resource (Resource), that is, to a single logical entity. A Resource may or may 888 not expose any fine structure.6 The Resource terminology and the duality of generation and curtailment 889 are from [EMIX]. 890 Under a demand response program, a Resource is capable of shedding load in response to Demand 891 Response Events, Electricity Price Signals or other system events (e.g. detection of under-frequency). 892 The VTN can query the actual state of a Resource with the EiFeedback service and request ongoing 893 information. The VTN can query the status of the VTN-VEN relationship using the EiStatus service. 894 Alternatively, a Resource may provide generation in response to similar information. The net effect is the 895 same. 896

5.3 Structure of Energy Interoperation Services and Operations 897

Energy Interoperation defines a web services implementation to formally describe the services and 898 interactions, but fully compliant services and operations may be implemented using other technologies. 899 We divide the services into four broad categories: 900

• Transactive Services—for implementing energy transactions, registration, and tenders 901 • Event Services—for implementing events and feedback 902 • Enrollment Services—for identifying and qualifying service providers, resources, and more 903 • Support Services—for additional capabilities 904

The structure of each section is a table with the service name, operations, service provider and 905 consumer, and notes in columns. 906 The services are grouped so that profiles can be defined for purposes such as price distribution, load and 907 usage projection, and Demand Response (with the functionality of [OpenADR]). This specification 908 defines three profiles, the OpenADR Profile, the TeMIX (Transactional EMIX) Profile, and the Price 909 Distribution Profile. 910 6 A finer level of granularity is sometimes called an asset. Assets are not in scope for this specification.

William Cox� 5/11/11 1:20 AM

Deleted: Message and Composition911

William Cox� 5/11/11 1:20 AMDeleted: customer is a participant912 William Cox� 5/11/11 1:20 AMDeleted: a913

William Cox� 5/11/11 1:20 AMDeleted: 914 William Cox� 5/11/11 1:20 AMDeleted: detection915 William Cox� 5/11/11 1:20 AMDeleted: State916



The normative XML schemas are in separate files, accessible through the [namespace] on the cover 917 page. 918

5.4 Naming of Services and Operations 919

The naming of services and operations follows a pattern. 920 Services are named starting with the letters Ei. Capitalization follows the Upper Camel Case convention. 921 Operations in each service use one or more of the following patterns. The first listed is a fragment of the 922 name of the initial service operation; the second is a fragment of the name of the response message 923 which acknowledges receipt, describes errors, and may pass information back to the invoker of the first 924 operation. 925 Create—Created An object is created and sent to the other Party 926 Cancel—Canceled A previously created request is canceled 927 Request—Sent A request is made for all objects relevant to this VTN-VEN relationship 928 Distribute An object (such as a price quote, a curtailment or generation request) is created 929 and sent without expectation of response 930 To construct an operation name for the EiEvent service, we concatenate the name fragment as listed, so 931 an operation to cancel an outstanding operation or event is called EiCreateEvent. 932 The pattern of naming is consistent with current work in the IEC Technical Committee 57 groups 933 responsible for the [TC57CIM]. 934

5.5 Push and Pull Patterns 935

The Service Operation naming includes application-level acknowledgements, which in nearly every case 936 carry application-level information, and allow for both push and pull of messages. 937 In this section, without loss of generality, we assume that the invoker is the VTN and the responder is the 938 VEN. 939 Push and Pull are with respect to the invoker of the operation. So if a VTN produces information that 940 describes a price quote, it can (in the case of Push) send it to its VENs. In the alternative, each VEN can 941 (in the case of Pull) request information by polling, or pulling it, from its VTN with respect to a particular 942 relationship or Market Context. 943 The Pull operation is performed by the VEN invoking the Request service operation pattern and fulfilled 944 with a Sent service operation pattern invoked by the VTN. 945 So a series of Push operations from a VTN to its VENs is analogous to a series of Pull operations from 946 the VEN to its VTN; by examining (e.g.) the absence of an Event that was visible on a previous Pull the 947 VEN can infer that that Event was canceled. The VEN could then send a Canceled service operation as if 948 it had received a Cancel service operation. 949 One special case is the Distribute pattern, which expects no response to the invoker. 950 The service quality of the Pull operations (and in particular the load on the VTN from repeated polling) is 951 not in scope for this specification. 952

5.6 Description of the Services and Operations 953

Each service is described as follows. In subsections we will 954 • Describe the service 955 • Show the table of operations 956 • Show the interaction patterns for the service operations in graphic form 957 • Describe the information model using [UML] for key artifacts used by the service 958 • Describe the operation payloads using [UML] for each operation 959

William Cox� 5/11/11 1:20 AMFormatted: Font:Not Bold, Font color:Auto



6 Transactive Services 960

Transactive Services define and support the lifecycle of transactions inside an overarching agreement, 961 from initial quotations and indications of interest to final settlement. The phases are 962

• Registration—to enable further phases. 963 • Pre-Transaction —non-binding quotes and binding tenders for transactions. 964 • Transaction Services—execution and management of transactions including transaction with 965

optionality. 966 • Post-Transaction—settlement, energy used or demanded, payment, position. 967

For transactive services, the roles are Parties and Counterparties. For event and resource services, the 968 Parties adopt a VTN or VEN role for interactions. The terminology of this section is that of business 969 agreements: tenders, quotes, and transaction execution and (possibly delayed) performance under an 970 option or DR transaction. 971 The register services identify the parties for future interactions. This is not the same as (e.g.) a program 972 registration in a demand response context—here, registration can lead to exchange of tenders and 973 quotes, which in turn may lead to a transaction which will determine the VTN and VEN roles of the 974 respective parties. 975

6.1 EiRegisterParty Service 976

Table 6—1: Register Services 977

Service Operation Response Service Consumer

Service Provider

Notes

EiRegister EiRegisterParty EiRegisteredParty Party Party

EiRegister EiRequestRegistration EiSendRegistration Party Party

EiRegister EiCancelRegistration EiCanceledRegistration Party Party

978

6.1.1 Interaction Pattern for the EiRegisterParty Service 979

This is the [UML] interaction diagram for the EiRegisterParty Service 980

William Cox� 5/11/11 1:20 AMDeleted: a981



982

Figure 6-1 Interaction Diagram for EiRegister Service 983

6.1.2 Information Model for the EiRegisterParty Service 984

The details of a Party are outside the scope of this specification. The application implementation needs to 985 identify additional information beyond that in the class EiParty. 986



987 Figure 6-2: EiParty UML Class Diagram 988

6.1.3 Operation Payloads for the EiRegisterParty Service 989

The [UML] class diagram describes the payloads for the EiFeedback service operations. 990

991 Figure 6-3: UML Class Diagram for EiRegisterParty Service Operation Payloads 992

6.2 Pre-Transaction Services 993

Pre-transaction services are those between parties that may or may not prepare for a transaction. The 994 services are EiTender and EiQuote. A quotation is not a tender, but rather a market price or possible 995 price, which needs a tender and acceptance to reach a transaction. 996



Price distribution as in what are sometimes called price signals is accomplished using the EiQuote 997 service. 998 As with other services, a Party MAY inquire from a counterparty what offers the counterparty 999 acknowledges as open by invoking the EiSendTender service to receive the outstanding tenders. 1000 There is no operation to “delete” a quote; when a quote has been canceled the counterparty MAY delete 1001 it at any time. To protect against recycled or dangling references, the counterparty SHOULD invalidate 1002 any identifier it maintains for the cancelled quote. 1003 Tenders, quotes, and transactions are [EMIX] artifacts, which contain terms such as schedules and prices 1004 in varying degrees of specificity or concreteness. 1005

Table 6—2: Pre-Transaction Tender Services 1006


Service Provider

Notes

EiTender EiCreateTender EiCreatedTender Party Party

EiTender EiRequestTender EiSentTender Party Party

EiTender EiSendTender EiReceivedTender Party Party NOT IN DIAGRAM

EiTender EiWithdrawTender EiWithdrewTender Party Party

1007

Table 6—3: Pre-Transaction Quote Services 1008


Service Provider

Notes

EiQuote EiCreateQuote EiCreatedQuote Party Party And sends the quote

EiQuote EiCancelQuote EiCanceledQuote Party Party

EiQuote EiRequestQuote EiSentQuote Party Party Request a quote or indication of interest (pull)

EiQuote EiDistributeQuote -- Party Party For broadcast or distribution of price (push)

1009

6.2.1 Interaction Pattern for the EiTender and EiQuote Services 1010

This is the [UML] interaction diagram for the EiTender Service. 1011

William Cox� 5/11/11 1:20 AMDeleted: [OpenADR] “1012

William Cox� 5/11/11 1:20 AMFormatted: Font:Italic

William Cox� 5/11/11 1:20 AMDeleted: ”1013

William Cox� 5/11/11 1:20 AMFormatted: Don't keep with next



1014

Figure 6-4 Interaction Diagram for the EiTender Service 1015

This is the [UML] interaction diagram for the EiQuote Service 1016



1017

Figure 6-5 Interaction Diagram for the EiQuote Service 1018

6.2.2 Information Model for the EiTender and EiQuote Services 1019

The information model for the EiTender Service and the EiQuote Service artifacts is that of [EMIX]. EMIX 1020 provides a product description as well as a schedule over time of prices and quantities. 1021

William Cox� 5/11/11 1:20 AMDeleted: Service1022



6.2.3 Operation Payloads for the EiTender Service 1023

The [UML] class diagram describes the payloads for the EiTender and EiQuote service operations. 1024

1025 Figure 6-6: UML Class Diagram for the Operation Payloads for the EiTender Service 1026

1027



6.2.4 Operation Payloads for the EiQuote Service 1028

1029 Figure 6-7: UML Class Diagram for the EiQuote Service Operation Payloads 1030

6.3 Transaction Management Services 1031

The service operations in this section manage the exchange of transactions. For demand response, the 1032 [overarching] agreement is the context in which events and response take place—what is often called a 1033 program is identified by the information element programName in the EiProgram service and elsewhere. 1034 There are no EiCancelTransaction or EiChangeTransaction operations. A compensating transaction 1035 SHOULD be created to clarify the economic effect of the reversal.7 1036

Table 6—4: Transaction Management Services 1037


Service Provider

Notes

EiTransaction EiCreateTransaction EiCreatedTransaction Party Party And send

7 This is consistent with the way that distributed agreement protocols such as [WS-BusinessActivity] manage compensation rather than cancelation.




Service Provider

Notes

Transaction

EiTransaction EiRequestTransaction EiSentTransaction Party Party

6.3.1 Interaction Patterns for the EiTransaction Service 1038

This is the [UML] interaction diagram for the EiTransaction Service: 1039

1040

Figure 6-8 Interaction Diagram for the EiTransaction Service 1041

6.3.2 Information Model for the EiTransaction Service 1042

Transactions are [EMIX] artifacts with the identification of the Parties. 1043



6.3.3 Operation Payloads for the EiTransaction Service 1044

The [UML] class diagram describes the payloads for the EiTransaction service operations. 1045

1046 Figure 6-9: UML Class Diagram of EiTransaction Service Operation Payloads 1047

6.4 Post-Transaction Services 1048

In a market of pure transactive energy, verification would be solely a function of meter readings. The seed 1049 standard for smart grid meter readings is the NAESB Energy Usage Information [NAESB EUI] 1050 specification. 1051 In today’s markets, with most customers on Full Requirements tariffs, the situation is necessarily more 1052 complex. Full Requirements describes the situation where purchases are not committed in advance. The 1053 seller is generally obligated to provide all that the buyer requires. Full requirements tariffs create much of 1054 the variance in today’s DR markets. 1055 These sections will apply the [NAESB EUI] along with [WS-Calendar].The [NAESB M&V] Business 1056 Practice is also relevant. This entire section is TBD. 1057

6.4.1 Energy Delivery Information 1058

NOTE THIS SERVICE NEEDS UPDATE 1059 These operations create, change, and allow exchange of Energy Usage Information. TBD pending 1060 ratification of [NAESB EUI] 1061

Table 6—5: Energy Usage Information 1062


Service Provider

Notes



EiUsage EiCreateUsage EiCreatedUsage Either Either

EiUsage EiChangeUsage EiChangedUsage Either Either

EiUsage EiCancelUsage EiCanceledUsage Either Either Cancel measurement request

EiUsage EiRequestUsage EiSentUsage Either Either

1063

6.4.1.1 Interaction Pattern for the EiUsage Service 1064

6.4.1.2 Information Model for the EiUsage Service 1065

6.4.1.3 Operation Payloads for the EiUsage Service 1066

The [UML] class diagram describes the payloads for the EiUsage service operations. 1067

6.4.2 Full Requirements Verification 1068

Full requirements verification involves a combination of usage and load measurement and information 1069 exchange; transactions often include demand charges (also called demand ratchets) that affect cost. 1070

6.4.2.1 Interaction Patterns for the Full Requirements Verification Service 1071

6.4.2.2 Information Model for the Full Requirements Verification Service 1072

6.4.2.3 Operation Payloads for the Full Requirements Verification Service 1073

The [UML] class diagram describes the payloads for the EiFullRequirementsVerification service 1074 operations. 1075



7 Enroll Service 1076

To enroll a Resource or a Service Provider is distinct from registering a Party—the former identifies and 1077 establishes an actor or a Resource with the VTN; the latter identifies a Party which is preparing to interact 1078 with other Parties in a transactive manner (and without regard to the VTN/VEN graph but with respect to a 1079 market or markets). 1080 The service operations EiRejectEnroll, EiRejectEnrollQualify, and EiAcceptEnroll may be optional in 1081 certain deployments. 1082 The entities described in the following table can be enrolled. These are described in the [UML] diagrams 1083 as concrete classes that inherit from the EnrollingEntity class. The strings are used to describe the entity; 1084 the standard approach to extensibility where a prefix of “x-“ indicates an extension SHALL be used. 1085 The types of entity used may depend on the implementation. All implementations SHALL support 1086 Resources. 1087

Table 7—1 Enrolling Entity Descriptions 1088

Entity String Description Definition

Resource resource An EMIX Resource with additional information

A Resource including performance envelope and additional information including Resource Name

ServiceProvider serviceProvider A Service Provider in general

A potential provider of services to the VTN in support of VTN business processes

SchedulingEntity schedulingEntity A provider of scheduling services

MeterAuthority meterAuthority A provider of metering services

LoadServingEntity lse An entity which supports loads rather than generation

TransmisionDistribution tdsp An entity which supports transmission and distribution of electricity

1089 1090

William Cox� 5/11/11 1:20 AMDeleted: Not all enrollments require the 1091 asynchronous multistage process with 1092 William Cox� 5/11/11 1:20 AMDeleted: or1093 William Cox� 5/11/11 1:20 AMDeleted: ; those enrollment business 1094 processes that do not use the first two service 1095 operations simply do not send them1096



Table 7—2: EiEnroll Service Operations 1097

Service

Operation Response Service Consum

er

Service Provide

r

Notes

EiEnroll

EiCreateEnroll EiAckEnroll VEN VTN This places an enrollment request; the response is asynchronous, hence an Acknowledgement rather than an EiCreatedEnroll

EiEnroll

EiRequestEnroll EiSendEntroll VEN VTN Requests current enrollment information with respect to the VEN

EiEnroll

EiCancelEnroll EiCanceledEnroll VEN VTN Cancel the specified enrollment(s)

EiEnroll

EiRejectEnroll EiRejectedEnroll VTN VEN An asynchronous response from the VTN rejecting enrollment

EiEnroll

EiRejectEnrollQualify

EiRejectedEnrollQualify

VTN VEN An asynchronous response rejecting the qualification of the enrollee. The Enrollment still exists.

EiEnroll

EiAcceptEnroll EiAcceptedEnroll VTN VEN An asynchronous response accepting the enrollment

7.1 Interaction Patterns for the EiEnroll Service 1098

This is the [UML] interaction diagram for the EiEnroll Service. 1099

William Cox� 5/11/11 1:20 AMDeleted: EiCreateEnroll1100



1101

Figure 7-1 Interaction Diagram for the EiEnroll Service 1102

7.2 Information Model for the EiEnroll Service 1103

The EiEnroll service has an abstract class for the respective types. The abstract class also has the entity 1104 identifier, type (as a string), and name. 1105 The standard values for the type are listed in Table 9-1 Enrolling Entity Descriptions. 1106 Other values MAY be used but MUST be prefixed by “x-“ as described in Appendix C 1107




1109

7.3 Operation Payloads for the EiEnroll Service 1110

The [UML] class diagram describes the payloads for the EiEnroll service operations. 1111 PENDING 1112




8 Event Services 1113

8.1 EiEvent Service 1114

The Event Service is used to call for performance under a transaction. The service parameters and event 1115 information distinguish different types of events. Event types include reliability events, emergency events, 1116 and more—and events MAY be defined for other actions under a transaction. For transactive services, 1117 two parties may enter into a call option. Invocation of the call option by the Promissee on the Promissor 1118 can be thought of as raising an event. But typically the Promissee may raise the event at its discretion as 1119 long as the call is within the terms of the call option transaction. 1120 An ISO that has awarded an ancillary services transaction to a party may issue dispatch orders, which 1121 can also be viewed as events. In this standard, what is sometimes called a price event is communicated 1122 using the EiSendQuote operation (see 6.2 “Pre-Transaction Services”). 1123

Table 8—1: Event Services 1124

Service Operation Response Operation

Service Consumer

Service Provider

Notes

EiEvent EiCreateEvent EiCreatedEvent VTN VEN Create invokes a new event

EiEvent EiChangeEvent EiChangedEvent VTN VEN

EiEvent EiCancelEvent EiCanceledEvent VTN VEN

EiEvent EiRequestEvent EiSentEvent Either Either

Since the event is the core Demand Response information structure, we begin with Unified Modeling 1125 Language [UML] diagrams for the EiEvent class and for each of the operation payloads. 1126

8.1.1 Interaction Patterns for the EiEvent Service 1127

This is the [UML] interaction diagram for the EiEvent Service. 1128 NOTE FIGURE IS CROPPED 1129

William Cox� 5/11/11 1:20 AMDeleted: historically 1130



1131

Figure 8-1 Interaction Pattern for the EiEvent Service 1132

1133

8.1.2 Information Model for the EiEvent Service 1134

The key class is EiEvent, which has associations with the classes Location, EventInfo, Sequence (from 1135 [WS-Calendar], and Program. See Figure 8-2below. 1136 An event has certain information including 1137

• A schedule (and a reference to the schedule)—attributes schedule and scheduleGluonRef.(Note: 1138 a Schedule includes 1 or more intervals, each of which could have a different program level, 1139 price, or whatever other information is being communicated by this Event.) 1140

• An identifier for the event—eventID 1141 • The program or agreement under which the event was issued—program 1142 • A modification counter, a timestamp for the most recent modification, and a reason—1143

modificationNumber, modificationDateTime, and modificationReason 1144

William Cox� 5/11/11 1:20 AMDeleted: See the figure 1145



• A location to which the event applies—location—which may be a geospatial location [OGC], an 1146 address [UBL], or grid electrical coordinates. 1147

• Baseline value and a timestamp for that value, used to compare curtailment and “normal” 1148 usage—energyBaselineValue and energyBaselineTimestamp 1149

• Information on status, comments, and other information—notificationAcknowledgement, 1150 operatingDay, performanceComment, reportingInterval, responseValue, status, and vtnComment 1151

1152

1153 Figure 8-2: UML Class Diagram for the EiEvent and Associated Classes 1154



8.1.3 Operation Payloads for the EiEvent Service 1155

The [UML] class diagram describes the payloads for the EiEvent service operations. 1156

1157 Figure 8-3: UML Class Diagram for EiEvent Service Operation Payloads 1158

1159



8.2 Feedback Service 1160

NOTE THIS SECTION NEEDS TO CHANGE – SEE Jira Item ENERGYINTEROP-409 1161 Feedback communicates information about the state of the Resource as it responds to an Event signal. 1162 This is distinct from Status, which communicates information about the state of the Event itself. See 1163 Section 9.3 “Status Service” for a discussion of Status. 1164 EiFeedback operations are independent of EiEvent operations in that they can be requested at any time 1165 independent of the status or history of EiEvents. 1166 EiFeedback operations can be timed using the feedbackCycle attribute and the associated service 1167 operations. 1168

Table 8—2: Feedback Service 1169


Service Provider

Notes

EiFeedback EiCreateFeedback EiCreatedFeedback VTN VEN One time or periodic response

EiFeedback EiCancelFeedback EiCanceledFeedback VTN VEN

EiFeedback EiRequestResponseSched EiSentResponseSched VTN VEN

EiFeedback EiStopFeedback EiStoppedFeedback VTN VEN Periodic response termination

EiFeedback EiSendFeedback EiReceivedFeedback VEN VTN The carrier for period response

8.2.1 Interaction Pattern for the EiFeedback Service 1170

This is the [UML] interaction diagram for the EiFeedback Service. 1171

William Cox� 5/11/11 1:20 AMDeleted: provides1172 William Cox� 5/11/11 1:20 AMDeleted: section 1173



1174

Figure 8-4 Interaction Diagram for the EiFeedback Service 1175

8.2.2 Information Model for the EiFeedback Service 1176

EiFeedback is requested by the VTN and supplied by the VEN(s). 1177

1178 Figure 8-5: UML Class Diagram for the EiFeedback Class 1179



8.2.3 Operation Payloads for the EiFeedback Service 1180

The [UML] class diagram describes the payloads for the EiFeedback service operations. The diagram for 1181 Feedback payloads follows the EiResponseSchedule payloads. 1182

1183 Figure 8-6: UML Class Diagram for EiFeedback service operations 1184



1185 Figure 8-7: UML Class Diagram for EiFeedback Service Operation Payloads 1186

8.3 EiProgram Service 1187

NOTE: THIS SERVICE WILL BE RENAMED OR DELETED POST WD23 1188 Programs for demand response vary considerably. One area of variation is in how many levels of 1189 requested response are defined, and what they are called. The EiProgram service distributes Program 1190 Calls, which are simple levels for requested action. The levels are purely nominal, and are structured so 1191 that any program with N levels of requested response can be represented easily and mapped to and 1192 from. The EiProgram services maps any number of nominal levels to a simple numeric model, allowing 1193 the same equipment to function in programs with any number of levels, and with optional application level 1194 mapping (outside the scope of this standard) for display or other purposes. 1195



William Cox� 5/11/11 1:20 AMMoved down [9]: This is analogous to the 1197 EiQuote service, used for communicating full 1198 [EMIX] price and product definition quotes.1199 William Cox� 5/11/11 1:20 AMMoved up [8]: Programs for demand 1200 response vary considerably. One area of 1201 variation is in how many levels of requested 1202 response are defined, and what they are called. 1203



This is analogous to the EiQuote service, used for communicating full [EMIX] price and product definition 1204 quotes. 1205 1206 Some examples of programs and levels are 1207

• OpenADR—Four levels: Low, Moderate, High, Special [emergency] 1208 • Smart Energy Profile 2—Three levels: Low, Moderate, High 1209 • EPA Energy Star 2.0 Interfaces—Four levels: Green, Amber, Orange, Red 1210

EiRequestProgram and EiSentProgram respectively request and send Program Metadata, which in this 1211 version of this standard includes the number of levels (responseUpperLimit, with the lower limit always 1212 being the integer one) and the so-called normal level (responseNormalValue, which must be in 1 to the 1213 responseUpperLimit inclusive). Not all programs will assume an ordering, and instead may use purely 1214 nominal levels, in which case responseNormalValue will be of limited use. 1215 Program Calls [“ProgCalls”] are communicated from a VTN to a VEN or by broadcast.8 1216

Table 8—3: EiProgram Service 1217


Service Provider

Notes

EiProgram EiRequestProgram EiSentProgram VEN VTN Gets selected Program metadata

EiProgram EiCreateProgCall EiCreatedProgCall Party Party And sends the Call

EiProgram EiCancelProgCall EiCanceledProgCall Party Party

EiProgram EiRequestProgCall EiSentProgCall Party Party Request outstanding Calls (pull)

EiProgram EiDistributeProgCall -- Party Party For broadcast or distribution of Calls (push)

1218

8.3.1 Interaction Patterns for the EiProgram Service 1219

This is the [UML] interaction diagram for the EiProgram Service 1220

8 A negotiation on program levels communicated and understood might be a useful extension, perhaps defaulting to three levels.


William Cox� 5/11/11 1:20 AMDeleted: ,1221






1224

Figure 8-8 Interaction Diagram for the EiProgram Service NOTE NAME IS CHANGING 1225



8.3.2 Information Model for the EiProgram Service 1226

The key class is EiProgram, which has associations with the classes Location, EventInfo, Sequence (from 1227 [WS-Calendar], and Program. See the figure below. 1228

1229 Figure 8-9: UML Class Diagram for the EiProgram Class 1230

1231



8.3.3 Operation Payloads for the EiProgram Service 1232

The [UML] class diagram describes the payloads for the EiProgram service operations. 1233

1234 Figure 8-10: UML Class Diagram for EiProgram Service Operation Payloads 1235



9 Support Services 1236

Users of [OpenADR] found that they needed to be able to constrain the application of remote DR 1237 services. For The DR Operator, advanced knowledge of these constraints improved the ability to predict 1238 results. The services in this schedule are based on the services used to tailor expectations in 1239 [OpenADR]. 1240 Constraints and OptOut are similar in that they communicate when an event will not be acted upon. 1241 Constraints are long-term restrictions on response and are often set at registration or transaction 1242 negotiation; OptOut is a short-term restriction on likely response. 1243 The combination of Constraints and OptOut states together (a logical or) defines the committed response 1244 from the VEN. 1245 Constraints and OptOut apply to curtailment and DER interactions, and only indirectly to price distribution 1246 interactions. 1247

9.1 EiConstraint Service 1248

NOTE This service and EiOpt need to be completely rewritten using Expectations. 1249 Constraints are set by the VEN and indicate when an event may or may not be accepted and executed by 1250 that VEN. The constraints (and OptOut schedules) for its VENs help the VTN estimate response to an 1251 event or request. 1252 Constraints are a long-term availability description and may be complex. The next section describes 1253 OptOut and how opting out affects predicted behavior. 1254 When constraints are set, opting in or out does not affect the constraints—opting out is temporary 1255 unavailability, which may have transaction consequences if an event is created during the optout period. 1256 The modeling for constraints includes attributes such as blackout intervals, valid intervals, and behavior 1257 indications for the situation where an EiEvent overlaps a constrained time interval. 1258 Exactly one of Constraint acceptSchedules and notAcceptSchedule MAY be provided. If both are 1259 provided, only the acceptSchedule SHALL be used. 1260 Constraint schedules SHALL be overridden by any OptState in effect. 1261

Table 9—1: Constraint Service 1262


Service Provider

Notes

EiConstraint EiCreateConstraint EiCreatedConstraint VEN VTN

EiConstraint EiChangeConstraint EiChangedConstraint VEN VTN

EiConstraint EiDeleteConstraint EiDeletedConstraint VEN VTN

EiConstraint EiRequestConstraint EiSentConstraint VEN VTN To ensure that the VTN constraints match the VEN description or for recovery

The class EiConstraintBehavior defines how an issued EiEvent that conflicts with the current EiConstraint 1263 is performed: 1264

• ACCEPT – accept the issued EiEvent regardless of conflicts with the EiConstraint 1265 • REJECT – reject any EiEvent whose schedule conflicts with the EiConstraint 1266

William Cox� 5/11/11 1:20 AMDeleted: state1267



• FORCE – regardless of what the issued DR events parameters are (even if there is no conflict) 1268 force them to be the parameters that were configured as part of the program.9 1269

• RESTRICT – modify the EiEvent parameters so that they fall within the bounds of the 1270 EiConstraint 1271

9.1.1 Interaction Patterns for the EiConstraint Service 1272

This is the [UML] interaction diagram for the EiConstraint Service. 1273

1274

Figure 9-1 Interaction Pattern for the EiConstraint Service 1275

1276

9 This requires further definition when Program metadata is defined.



9.1.2 Information Model for the EiConstraint Service 1277

1278 Figure 9-2: UML Class Diagram for the EiConstraint and Associated Classes 1279

William Cox� 5/11/11 1:20 AMDeleted: Constraint1280



9.1.3 Operation Payloads for the EiConstraint Service 1281

The [UML] class diagram describes the payloads for the EiConstraint service operations. 1282

1283 Figure 9-3: UML Class Diagram for EiConstraint Service Operation Payloads 1284

9.2 Opt Service 1285

NOTE This service and EiConstraint need to be completely rewritten using Expectations. 1286 The Opt service creates and communicates Opt In and Opt Out schedules from the VEN to the VTN. 1287 Schedules are combined with EiConstraints to give a complete picture of the willingness of the VEN to 1288 respond to EiEvents that may be created by the VTN. 1289



Exactly one of Opt Out and Opt In schedules MAY be provided. If both are provided, Opt In SHALL be 1290 used. 1291 Opt schedules SHALL override any Constraints in place while there is an OptState in effect. 1292

Table 9—2: Opt-Out Service 1293

Service

Operation Response Service Consum

er

Service

Provider

Notes

EiOpt EiCreateOptState EiCreatedOptState VEN VTN

EiOpt EiChangeOptState EiChangedOptState VEN VTN

EiOpt EiCancelOptState EiCanceledOptState VEN VTN

EiOpt EiRequestOptState EiSentOptState VEN VTN

9.2.1 Interaction Patterns for the EiOpt Service 1294

This is the [UML] interaction diagram for the EiOpt Service. 1295

1296

Figure 9-4 Interaction Diagram for the EiOpt Service 1297


William Cox� 5/11/11 1:20 AMDeleted: EiDeleteOptState1298 William Cox� 5/11/11 1:20 AMDeleted: EiDeletedOptState1299



9.2.2 Information Model for the EiOpt Service 1300

Opting in or out is a temporary situation indicating that the VEN will or will not respond to a particular 1301 event or in a specific time period, without changing the potentially complex Program Constraints. The 1302 EiOpt schedule is an [EMIX] businessSchedule. 1303

1304 Figure 9-5: UML Class Diagram for the EiOpt Class 1305

William Cox� 5/11/11 1:20 AMDeleted: Opt1306

William Cox� 5/11/11 1:20 AMDeleted: siutation1307



9.2.3 Operation Payloads for the Opt Out Service 1308

The [UML] class diagram describes the payloads for the EiOptout service operations. 1309

1310 Figure 9-6: UML Class Diagram for EiOptout Service Operation Payloads 1311

1312



9.3 Status Service 1313

Status communicates information about the state of an Event itself. This is distinct from Feedback which 1314 communicates information about the state of Resources as it responds to a DR Event signal. See section 1315 8.2 Feedback Service for a discussion of Feedback. 1316 This service requests information held by the VTN. 1317

Table 9—3: Status Services 1318


Service Provider

Notes

EiStatus EiRequestStatus EiSentStatus VEN VTN Status of outstanding Events known by the VTN

1319

9.3.1 Interaction Patterns for the EiStatus Service 1320

This is the [UML] interaction diagram for the EiStatus Service. 1321

1322

Figure 9-7 Interaction Pattern for the EiStatus Service 1323

9.3.2 Information Model for the EiStatus Service 1324

1325


William Cox� 5/11/11 1:20 AMDeleted: Status1326



1327 Figure 9-8: UML Class Diagram for the EiStatus Class 1328

9.3.3 Operation Payloads for the Status Service 1329

The [UML] class diagram describes the payloads for the EiStatus service operations. 1330

1331 Figure 9-9: UML Class Diagram for EiStatus Service Operation Payloads 1332



10 Security and Composition [Non-Normative] 1333

In this section, we describe the enterprise software approach to security and composition as applied to 1334 this Energy Interoperation specification. 1335 Service orientation has driven a great simplification of interoperation, wherein software is no longer based 1336 on Application Programming Interfaces (APIs) but is based on exchange of information in a defined 1337 pattern of services and service operations [SOA-RM]. 1338 The approach for enterprise software has evolved to defining key services and information to be 1339 exchanged, without definitively specifying how to communicate with services and how to exchange 1340 information—there are many requirements for distributed applications in many environments that cannot 1341 be taken into account in a service and information standard. To make such choices is the realm of other 1342 standards for specific areas of practice, and even there due care must be taken to avoid creating a 1343 monoculture of security.10 1344

10.1 Security and Reliability Example 1345

Different interactions require different choices for security, privacy, and reliability. Consider the following 1346 set of specifics. (We repeat the figure and re-label it.). 1347

1348 Figure 10-1: Web of Example DR Interactions 1349

We specifically model a Reliability DR Event initiated by the Independent System Operator11 A, who 1350 sends a reliability event to its first-level aggregators B through E. Aggregator B, in turn invokes the same 1351 service on its customers (say real estate landlords) F, G, and H. 1352 Those customers might be industrial parks with multiple facilities, real estate developments with multiple 1353 tenants, or a company headquarters with facilities in many different geographical areas, which would 1354 invoke the same operation on their VENs. 1355 For our example, say that G is a big-box store regional headquarters and I, J, and L are their stores in the 1356 affected area. 1357 Each interaction will have its own security and reliability composed as needed—the requirements vary for 1358 specific interactions. For example 1359

• For service operations between A to B, typical implementations include secure private frame-1360 relay networks with guaranteed high reliability and known latency. In addition, rather than relying 1361

10 See e.g. the STUXNET worm effects on a monoculture of software SCADA systems, 2010. See http://en.wikipedia.org/wiki/Stuxnet 11 Using North American Terminology.



on the highly reliable network, in this case A requires an acknowledgment message from B back 1362 to A proving that the message was received. 1363

• From the perspective of the ISO, the communication security and reliability between B and its 1364 customers F, G, and H may be purely the responsibility of B, who in order to carry out B’s 1365 transaction commitments to A will arrange its business and interactions to meet B’s business 1366 needs. 1367

• G receives the signal from aggregator B. In the transaction between G and B, there are service, 1368 response, and likely security and other requirements. To meet its transactional requirements, the 1369 service operations between B and G will be implemented to satisfy the business needs of both B 1370 and G. For our example, they will use the public Internet with VPN technology and explicit 1371 acknowledgement, with a backup of pagers and phone calls in the unlikely event that the primary 1372 communication fails. And each message gets an explicit application level acknowledgement. 1373

• Security between B and G depends on the respective security models and infrastructure 1374 supported by B and G—no one size will fit all. So that security will be used for that interaction 1375

• The big box store chain has its own corporate security architecture and implementation, as well 1376 as reliability that meets its business needs—again, no one size will fit all, and there is tremendous 1377 variation; there is no monoculture of corporate security infrastructures. 1378

• Store L has security, reliability, and other system design and deployment needs and 1379 implementations within the store. These may or may not be the same as the WAN connection 1380 from regional headquarters G, in fact are typically not the same (although some security aspects 1381 such as federated identity management and key distribution might be the same). 1382

• Store L also has a relationship with aggregator E, which we will say for this example is Store L’s 1383 local utility; the Public Utility Commission for the state in which L is located has mandated (in this 1384 example) that all commercial customers will use Energy Interoperation to receive certain 1385 mandated signals and price communications from the local utility. The PUC, the utility, and the 1386 owner of the store L have determined the security and reliability constraints. Once again, one size 1387 cannot fit all—and if there were one “normal” way to accommodate security and reliability, there 1388 will be a different “normal” way in different jurisdictions. 1389

So for a simple Demand Response event distribution, we have potentially four different security profiles 1390 The following table has sample functional names for selected nodes. 1391

Table 10—1: Interactions and Actors for Security and Reliability Example 1392

Label Structure Role Possible Actor Names

A VTN System Operator

B VEN (wrt A), VTN (wrt F, G, H)

Aggregator

G VEN (wrt B), VTN (wrt I, J, L)

Regional Office

L VEN (wrt G and wrt E) Store

E VEN (wrt A, VTN wrt L) Local Utility

1393

10.2 Composition 1394

In state-of-the art software architecture, we have moved away from monolithic implementations and 1395 standards to ones that are composed of smaller parts. This allows the substitution of a functionally similar 1396 technology where needed, innovation in place, and innovation across possible solutions. 1397 In the rich ecosystem of service and applications in use today, we compose or (loosely) assemble 1398 applications rather than craft them as one large thing. See for example OASIS Service Component 1399



Architecture [OASIS SCA], which addresses the assembly, substitution, and independent evolution of 1400 components. 1401 A typical web browser or email system uses many standards from many sources, and has evolved rapidly 1402 to accommodate new requirements by being structured to allow substitution. The set of standards 1403 (information, service, or messaging) is said to be composed to perform the task of delivery of email. 1404 Rather than creating a single application that does everything, perhaps in its own specific way, we can 1405 use components of code, of standards, and of protocols to achieve our goal. This is much more efficient 1406 to produce and evolve than large integrated applications such as older customized email systems. 1407 In a similar manner, we say we compose the required security into the applications—say an aspect of 1408 OASIS [WS-Security] and OASIS Security Access Markup Language [SAML]—and further compose the 1409 required reliability, say by using OASIS [WS-ReliableMessaging] or perhaps the reliable messaging 1410 supported in an Enterprise Service Bus that we have deployed. 1411 A service specification, with specific information to be exchanged, can take advantage of and be used in 1412 many different business environments without locking some in and locking some out, a great benefit to 1413 flexibility, adoption, and re-use. 1414

10.3 Energy Interoperation and Security 1415

In this section we describe some specific technologies and standards in our palette for building a secure 1416 and reliable implementation of Energy Interoperation. Since Energy Interoperation defines only the core 1417 information exchanges and services, and other technologies are composed in, there is no optionality 1418 related to security or reliability required or present in Energy Interoperation. 1419 The information model in Energy Interoperation 1.0 is just that—an information model without security 1420 requirements. Each implementation must determine the security needs (outside the scope of this 1421 standard) broadly defined, including privacy (see e.g. OASIS Privacy Management Reference Model 1422 [ref]), identity (see e.g. OASIS Identity in the Cloud, OAISIS Key Management Inteoperability, OASIS 1423 Enterprise Key Management Infrastructure, OASIS Provisioning Services, OASIS Web Services 1424 Federation TC, OASIS Web Services Secure Exchange and more) 1425 Energy Interoperation defines services together with service operations, as is now best practice in 1426 enterprise software. The message payloads are defined as information models, and include such artifacts 1427 as Energy Market Information Exchange [EMIX] price and product definition, tenders, and transactions, 1428 the EiEvent artifacts defined in this specification, and all information required to be exchanged for price 1429 distribution, program event distribution, demand response, and distributed energy resources. 1430 This allows the composition and use of required interoperation standards without restriction, drawing from 1431 a palette of available standards, best practices, and technologies. The requirements to be addressed for 1432 a deployment are system issues and out of scope for this specification. 1433 As in other software areas, if a particular approach is commonly used a separate standard (or 1434 standardized profile) may be created. In this way, WS-SecureConversation composes WS-Reliability and 1435 WS-Security. 1436 So Energy Inteoperation defines the exchanged information, the services and operations, and as a matter 1437 of scope and broad use does not address any specific application as the security, privacy, performance, 1438 and reliability needs cannot be encompassed in one specification. Many of the TCs named above have 1439 produced OASIS Standards, 1440 (SEE http://www.oasis-open.org/committees/tc_cat.php?cat=security) 1441



11 Profiles [Normative] 1442

NOTE NEED TO UPDATE WITH SERVICE NAMES AND CORRECT SECTION NUMBERS 1443 These sections define the three normative profiles that are part of Energy Interoperation 1.0. 1444 A profile includes a selection of interfaces, services, and options for a particular purpose. 1445

11.1 OpenADR [Normative] 1446

The OpenADR Profile defines the services required to implement functionality similar to that in 1447 [OpenADR]. The inclusion of the Energy Interoperation structure of VTNs and VENs, as well as use of 1448 the Energy Market Information Exchange [EMIX] cross-cutting price and product definition standard and 1449 WS-Calendar [WS-Calendar] based on the IETF [iCalendar] RFC updates and gives a broader range of 1450 applicability in what has been described as the OpenADR 2 Profile. 1451 We present in simplified tabular form the Energy Interoperation services required as part of the OpenADR 1452 Profile. When a service is included, all of the listed operations are required, so we list only the service 1453 name and the section of this document. 1454

Service Section Notes

EiRegisterParty 8.1 Register to identify and receive information

EiQuote 8.2 EiDistributeQuote for distributing dynamic prices (push), other operations for pull including block and tier tariff communication

EiEvent 9.1 The core event functions and information models

EiFeedback 9.2 The ability to set periodic or one-time information on the state of a Resource

EiProgram 9.3 Simplified levels to describe price

EiContraint 10.1 Constraints on the possible time a Resources is available or not

EiOpt 10.2 Overrides the Constraints; Opt In and Opt Out are supported separately

EiStatus 10.3 Determine status of events



1455

11.2 TEMIX [Normative] 1456

The Tranactive EMIX (TEMIX) Profile defines the services required to implement functionality for energy 1457 market interactions. 1458 We present in simplified tabular form the Energy Interoperation services required as part of the TEMIX 1459 Profile. When a service is included, all of the listed operations are required, so we list only the service 1460 name and the section of this document. 1461 1462



EiQuote 8.2 EiDistributeQuote for distributing dynamic prices (push), other components for pull

EiTender 8.2 The basic offer of agreement is called a tender

EiTransaction 8.3 The core services to reach agreement

1463

11.3 Price Distribution [Normative] 1464

The OpenADR Profile defines the services required to implement functionality similar to that in 1465 [OpenADR]. The inclusion of the Energy Interoperation structure of VTNs and VENs, as well as use of 1466 the Energy Market Information Exchange [EMIX] cross-cutting price and product definition standard and 1467 WS-Calendar [WS-Calendar] based on the IETF [iCalendar] RFC updates and gives a broader range of 1468 applicability in what has been described as the OpenADR 2 Profile. 1469 We present in simplified tabular form the Energy Interoperation services required as part of the OpenADR 1470 Profile. When a service is included, all of the listed operations are required, so we list only the service 1471 name and the section of this document. 1472 1473



EiQuote 8.2 EiDistributeQuote for distributing dynamic prices (push), other components for pull

1474



12 Conformance 1475

Up until this draft, the core services and payloads have been changing too often for the committee to 1476 focus closely on conformance issues. For Interoperability on the scale of the grid, the conformance 1477 requirements require the inputs from a wide range of perspectives and approaches. The Technical 1478 Committee especially welcomes suggestions and requirements for conformance. 1479 The SGIP SGTCC has just released v1.0 of their Interoperability Process Reference Manual: 1480 http://collaborate.nist.gov/twiki-sggrid/pub/SmartGrid/SGTCCIPRM/SGTCC_IPRM_Version_1.0.pdf 1481 In section 2 they state, 1482

In the context of interoperability, product certification is intended to provide high confidence that a 1483 product, when integrated and operated within the Smart Grid, will function as stated under 1484 specific business conditions and / or criteria. The IPRM defines criteria, recommendations, and 1485 guidelines for product interoperability and conformance certification. It is important to understand 1486 "Interoperability" has no meaning for a single product but for a relationship among two or more 1487 products. Alternatively, conformance does have meaning for one product as it applies to its 1488 meeting the requirements of the standard or test profile. 1489

Section 5 of the IPRM v1.0 further states that conformance testing precedes Interoperability testing, and 1490 is part of it. 1491

• conformance testing is a part of the interoperability testing process (per line 175 of the IPRM 1492 v1.0) 1493

• Line 187 states "Prior to interoperability testing, a product is tested for conformance to the 1494 specification at each relevant OSI layer." 1495

• Line 203 "conformance testing is in general "orthogonal", or separate from interoperability testing. 1496 Nevertheless, conformance and interoperability testing are interrelated in a matrix relationship." 1497

This specification cannot provide complete conformance requirements for all implementations. 1498 Implementations built upon Energy Interoperation will need to develop their own conformance profiles. 1499 For example, different implementations will support a different mix of business-to-business and business-1500 to-consumer, with quite different privacy requirements. Each will require its own security, message 1501 requirements (what part of EI to implement), and what other standards are included. 1502 Conformance testing requires that any product that claims to implement EI (as detailed in its PICS 1503 statement, which might indicate a limited set of services), can in fact implement these services according 1504 to the standard, correctly forming each supported service request, and consuming responses, producing 1505 responses as needed, with acceptable parameters, and failing in appropriate and defined ways when 1506 presented with bad data. 1507 The Technical Committee welcomes comments that point to testing and conformance standard or that 1508 discuss the roles of those standards in an interoperability testing process. The Technical Committee also 1509 welcomes suggestions for the organization that should be the Interoperability Testing and Certification 1510 Authority for Energy Interoperation. 1511 1512




A. Background and Development history 1513

There is a significant disconnect between customer load and the value of energy. The demand is not 1514 sensitive to supply constraints; the load is not elastic; and the market fails to govern consumer behavior. 1515 In particular, poor communications concerning high costs at times of peak use cause economic loss to 1516 energy suppliers and consumers. There are today a limited number of high demand periods (roughly ten 1517 days a year, and only a portion of those days) when the failure to manage peak demand causes immense 1518 costs to the provider of energy; and, if the demand cannot be met, expensive degradations of service to 1519 the consumer of energy. 1520 As the proportion of alternative energies on the grid rises, and more energy comes from intermittent 1521 sources, the frequency and scale of these problems will increase and there will be an increasing need for 1522 24/7 coordination of supply and demand. In addition, new electric loads such as electric vehicles will 1523 increase the need for electricity and with new load characteristics and timing. 1524 Energy consumers can use a variety of technologies and strategies to shift energy use to times of lower 1525 demand as well as to reduce use during peak periods. This shifting and reduction can reduce the need for 1526 new power plants, and transmission and distribution systems. These changes will reduce the overall 1527 costs of energy through greater economic efficiency. This process is known by various names, including 1528 load shaping, demand shaping, and demand response (DR). Consistent interfaces and messages for DR 1529 is a high priority cross-cutting issue identified in the NIST Smart Grid Interoperability Roadmap. 1530 Distributed energy resources, including generation and storage, now challenge the traditional hierarchical 1531 relationship of supplier and consumer. Alternative and renewable energy sources may be located closer 1532 to the end nodes of the grid than traditional bulk generation, or even within the end nodes. Wind and solar 1533 generation, as well as industrial co-generation, allow end nodes to sometimes supply. Energy storage, 1534 including mobile storage in plug-in hybrid vehicles, means that even a device may be sometimes a 1535 supplier, sometime a customer. As these sources are all intermittent, they increase the challenge of 1536 coordinating supply and demand to maintain the reliability of the electric grid. These resource, with their 1537 associated issues, are generally named distributed energy resources (DER). The NIST Smart Grid 1538 Interoperability Roadmap, this specification, and [EMIX] see a continuum between DR and DER. 1539 Better communication of energy prices addresses growing needs for lower-carbon, lower-energy 1540 buildings, net zero-energy systems, and supply-demand integration that take advantage of dynamic 1541 pricing. Local generation and local storage require that the consumer (in today's situation) make 1542 investments in technology and infrastructure including electric charging and thermal storage systems. 1543 People, buildings, businesses and the power grid will benefit from automated and timely communication 1544 of energy pricing, capacity information, and other grid information. 1545 Consistency of interface for interoperation and standardization of data communication will allow 1546 essentially the same model to work for homes, small businesses, commercial buildings, office parks, 1547 neighborhood grids, and industrial facilities, simplifying interoperation across the broad range of energy 1548 providers, distributors, and consumers, and reducing costs for implementation. 1549 These communications will involve energy consumers, producers, transmission systems, and distribution 1550 systems. They must enable aggregation of production, consumption, and curtailment resources. These 1551 communications must support market makers, such as Independent System Operators (ISOs), utilities, 1552 and other evolving mechanisms while maintaining interoperation as the Smart Grid evolves. On the 1553 consumer side of these interfaces, building and facility agents will be able to make decisions on energy 1554 sale, purchase, and use that fit the goals and requirements of their home, business, or industrial facility. 1555 The new symmetry of energy interactions demands symmetry of interaction. A net consumer of energy 1556 may be a producer when the sun is shining, the wind is blowing, or an industrial facility is cogenerating12. 1557 12 Cogeneration refers the combined generation of multiple energy resources, i.e., a boiler that both spins a turbine to generate electricity and produces team to run an industrial process. Cogeneration can include any number of energy distributions, including heat, cold, pressure, et al.



Each interface must support symmetry as well, with energy and economic transactions able to flow each 1558 way. 1559 Energy Interoperation defines the market interactions between smart grids and their end nodes 1560 (Customers), including Smart Buildings and Facilities, Enterprises, Industry, Homes, and Vehicles. Market 1561 interactions are defined here to include all informational communications and to exclude direct process 1562 control communications. This document defines signals to communicate interoperable dynamic pricing, 1563 reliability, and emergency signals to meet business and energy needs, and scale, using a variety of 1564 communication technologies. 1565



B. Glossary 1566

No definition in this glossary supplants normative definitions in this or other specifications. They are here 1567 merely to provide a guidepost for readers at to terms and their special uses. Implementers will want to be 1568 familiar with all referenced standards. 1569 Agreement is broad context that incorporates market context and programs. Agreement definitions are 1570

out of scope in Energy Interoperation. 1571 DR Resource: see Resource. 1572 EMIX: As used in this document, EMIX objects are descriptions applied to a WS-Calendar Sequence. 1573

EMIX defines Resource capabilities, used in tenders to match capabilities to need, and in 1574 Products, used in tenders and in specific performance and execution calls. 1575

Feedback: Information about the state of a Resource; typically in relation to planning or executing a 1576 response to an Event 1577

Resource (as used in Energy Interoperation): a Resource is a logical entity that is dispatchable. The 1578 Resource is solely responsible for its own response. A resource description specifies the 1579 performance envelope for a Resource. If a Resource can participate in multiple markets, it may 1580 have multiple desriptions. 1581

Resource (as defined in EMIX): A Resource is something that can describe its capabilities in a Tender 1582 into a market. How those Capabilities vary over time is defined by application of the Capability 1583 Description to a WS-Calendar Sequence. See [EMIX]. 1584

Status: Information about an Event, perhaps in relation to a specific Resource. 1585 Sequence: A set of temporally related intervals with a common relation to some informational artifact as 1586

defined in WS-Calendar. Time invariant elements are in the artifact (known as a gluon) and time-1587 varying elements are in each interval. 1588

Tender: A tender is an offering for a Transaction. See Transaction. 1589 Transaction: A binding commitment between parties entered into under an Agreement. 1590 VEN – see Virtual End Node 1591 Virtual End Node (VEN): The VEN has operational control of a set of resources and/or processes and is 1592

able to control the output or demand of these resources in affect their generation or utilization of 1593 electrical energy intelligently in response to an understood set of smart grid messages. The VEN 1594 may be either a producer or consumer of energy. The VEN is able to communicate (2-way) with a 1595 VTN receiving and transmitting smart grid messages that relay grid situations, conditions, or 1596 events. A VEN may take the role of a VTN in other interactions. 1597

Virtual Top Node (VTN): a Party that is in the role of aggregating information and capabilities of 1598 distributed energy resources. The VTN is able to communicate with both the Grid and the VEN 1599 devices or systems in its domain. A VTN may take the role of a VEN interacting with another 1600 VTN. 1601

VTN – see Virtual Top Node 1602



C. Extensibility in Energy Interoperation 1603

Extensibility was a critical design constraint for Energy Interoperation. Extensibility allows the Energy 1604 Interoperation specification to be used in markets and in interactions that were not represented on the 1605 Technical Committee. Formal extensibility rules also create a set of complaint extensions for 1606 incorporation into later versions that are already compliant. 1607

C.1 Extensibility in Enumerated values 1608

EI defines a number of enumerations. Some of these, such as measurements of power, are predictably 1609 stable. Others, such as market contracts or energy sources, may well have new elements added. In 1610 general, these accept any string beginning with “x-“ as a legal extension. In particular, these are defined 1611 using the following mechanism in the formal schemas (XSD’s). 1612 In ei.xsd, the extensibility pattern is defined. This pattern look like: 1613

<xs:simpleType name="EiExtensionType"> 1614 <xs:annotation> 1615 <xs:documentation>Pattern used for extending string 1616 enumeration, where allowed</xs:documentation> 1617 </xs:annotation> 1618 <xs:restriction base="xs:string"> 1619 <xs:pattern value="x-\S.*"/> 1620 </xs:restriction> 1621 </xs:simpleType> 1622

Non-extensible enumerated types look like this: 1623

<xs:simpleType name="VoltageUnitsType"> 1624 <xs:restriction base="xs:string"> 1625 <xs:enumeration value="MV"/> 1626 <xs:enumeration value="KV"/> 1627 <xs:enumeration value="V"/> 1628 </xs:restriction> 1629 </xs:simpleType> 1630

In this case, we use the suffix “EnumeratedType” to allow for the possibility of other Measurement 1631 Protocols that are not enumerated. Actual compliance, though, is based upon the type: 1632

<xs:simpleType name="MeasurementProtocolType"> 1633 <xs:union memberTypes="power:MeasurementProtocolEnumeratedType 1634 emix:EmixExtensionType"/> 1635 </xs:simpleType> 1636

That is, valid values for the measurement protocol are the enumerated values, and any that match the 1637 extension pattern “x-*” 1638

C.2 Extension of Structured Information Collective Items 1639

EI anticipates adding some information structures that are more complex than simple strings can be 1640 extended as well. A challenge for these items is that they are more complicated and so require formal 1641 definition. Formal definitions, expressed as additions to schema, could require changes to the 1642 specification. Without formal definition, it is difficult for trading partners to agree on valid messages. 1643 EI uses abstract classes for many information exchanges. For example, trading partners could agree on 1644 the exchange of larger or smaller lists of quality measures. Many measures of power quality are defined 1645 in power-quality.xsd. Quality consists of an array of elements that are derived from the abstract base 1646 quality element. 1647

<xs:complexType name="PowerQualityType"> 1648



<xs:annotation> 1649 <xs:documentation>Power Quality consists of a number of measures, 1650 based on contract, negotiation, and local regulation. Extend Power Quality to 1651 incorporate new elements by creating additional elements based on 1652 PowerQualityBaseType</xs:documentation> 1653 </xs:annotation> 1654 <xs:sequence> 1655 <xs:element name="measurementProtocol" 1656 type="power:MeasurementProtocolType"/> 1657 <xs:element name="constraints" type="power:ArrayOfPowerQualities"/> 1658 </xs:sequence> 1659 </xs:complexType> 1660

A practitioner who wanted to add an additional quality type would need to develop a description and 1661 instantiation of that type based on the abstract base, similar to that used below. The implementation 1662 refers to the substitution group: 1663

<xs:element name="supplyVoltageVariations" 1664 type="power:SupplyVoltageVariationsType" 1665 substitutionGroup="power:basePowerQualityMeasurement"/> 1666

and the type extends the abstract base class BasePowerQualityMeaurementType: 1667

<xs:complexType name="SupplyVoltageVariationsType" mixed="false"> 1668 <xs:complexContent mixed="false"> 1669 <xs:extension base="power:BasePowerQualityMeasurementType"> 1670 <xs:sequence> 1671 <xs:element name="count" type="xs:int"/> 1672 </xs:sequence> 1673 </xs:extension> 1674 </xs:complexContent> 1675 </xs:complexType> 1676

The resulting schema, which references the approved EI schemas, but does not change them, can then 1677 be distributed to business partners to validate the resulting message exchanges. 1678 1679



D. Acknowledgements 1680

The following individuals have participated in the creation of this specification and are gratefully 1681 acknowledged: 1682 Participants: 1683

Hans Aanesen, Individual 1684 Bruce Bartell, Southern California Edison 1685 Timothy Bennett, Drummond Group Inc. 1686 Carl Besaw, Southern California Edison 1687 Anto Budiardjo, Clasma Events, Inc. 1688 Edward Cazalet, Individual 1689 Joon-Young Choi, Jeonju University 1690 Kevin Colmer, California Independent System Operator 1691 Toby Considine, University of North Carolina 1692 William Cox, Individual 1693 Sean Crimmins, California Independent System Operator 1694 Phil Davis, Schneider Electric 1695 Sharon Dinges, Trane 1696 Robert Dolin, Echelon Corporation 1697 Rik Drummond, Drummond Group Inc. 1698 Ernst Eder, LonMark International 1699 Thomas Ferrentino, Individual 1700 Craig Gemmill, Tridium, Inc. 1701 Girish Ghatikar, Lawrence Berkeley National Laboratory 1702 Gerald Gray, Southern California Edison 1703 Anne Hendry, Individual 1704 Thomas Herbst, Cisco Systems, Inc. 1705 David Holmberg, NIST 1706 Gale Horst, Electric Power Research Institute (EPRI) 1707 Ali Ipakchi, Open Access Technology International Inc. (OATi) 1708 Oliver Johnson, Tendril Networks, Inc. 1709 Sila Kiliccote, Lawrence Berkeley National Laboratory 1710 Ed Koch, Akuacom Inc 1711 Michel Kohanim, Universal Devices, Inc. 1712 Larry Lackey, TIBCO Software Inc. 1713 Derek Lasalle, JPMorganChase 1714 Jeremy Laundergan, Southern California Edison 1715 Benoit Lepeuple, LonMark International 1716 Edgardo Luzcando, Midwest ISO and ISO/RTO Council (IRC) 1717 Carl Mattocks, Individual 1718 Dirk Mahling, CPower 1719 Kyle Meadors, Drummond Group Inc. 1720 Scott Neumann, Utility Integration Solutions Inc. 1721 Robert Old, Siemens AG 1722 Mary Ann Piette, Lawrence Berkeley National Laboratory 1723 Donna Pratt, New York ISO and ISO/RTO Council (IRC) 1724 Ruchi Rajasekhar, Midwest Independent System Operator 1725 Jeremy Roberts, LonMark International 1726 Anno Scholten, Individual 1727 Pornsak Songkakul, Siemens AG 1728 Jane Snowdon, IBM 1729 Aaron Snyder, NIST 1730 William Stocker, New York ISO and ISO/RTO Council (IRC) 1731



Pornsak Songkakul, Siemens AG 1732 Robert Stayton, Individual 1733 Jake Thompson, EnerNOC 1734 Matt Wakefield, Electric Power Research Institute (EPRI) 1735 Douglas Walker, California Independent System Operator 1736 Evan Wallace, NIST 1737 Dave Watson, Lawrence Berkeley National Laboratory 1738 David Wilson, Trane 1739 Leighton Wolffe, Individual 1740 Brian Zink, New York Independent System Operator 1741

The Technical Committee also acknowledges the work of the contributing groups who did so much to 1742 bring requirements and use cases to the attention of the Committee. In particular, the ISO/RTO Council 1743 task force on Demand Response, the UCAIug OpenSG Task Force on OpenADR, and the NAESB Smart 1744 Grid Task Force provided invaluable guidance and frequent feedback. 1745 The following individuals have participated in the creation of this specification and are gratefully 1746 acknowledged: 1747 UCAIug OpenSG OpenADR Task Force: 1748

Albert Chiu, Pacific Gas & Electric 1749 Bruce Bartell, Southern California Edison 1750 Gerald Gray, Southern California Edison 1751 1752

The ISO / RTO Council Smart Grid Standards Project: 1753 We want to thank the IRC team, in particular those who directly participated in this Technical Committee: 1754

Edgardo Luzcando, Midwest ISO and ISO/RTO Council (IRC) 1755 Donna Pratt, New York ISO and ISO/RTO Council (IRC) 1756 William Stocker, New York ISO and ISO/RTO Council (IRC) 1757

The IRC team consisted of a large group of participants from ISOs and RTOs. See the IRC Smart Grid 1758 Standards web site for additional details about the project and team members - 1759 http://www.isorto.org/site/c.jhKQIZPBImE/b.6368657/k.CCDF/Smart_Grid_Project_Standards.htm 1760

1761 NAESB Smart Grid Standards Development Subcommittee Co-chairs: 1762

Brent Hodges, Reliant 1763 Robert Burke, ISO New England 1764 Wayne Longcore, Consumers Energy 1765 Joe Zhou, Xtensible Solutions 1766



E. Revision History 1767

1768

Revision Date Editor Changes Made

1.0 WD 01 Toby Considine Initial document, largely derived from OpenADR

1.0 WD 02 Toby Considine






1.0 WD 08 2010-03-09 Toby Considine Reduced core functions to two service groups, transactivel energy and eliminated references to managed energy

1.0 WD 09 2010-03-23 Toby Considine

1.0 WD 10 2010-05-11 William Cox Updated interaction model per analysis and drawings in TC meetings in April and early May

1.0 WD 11 2010-05-18 William Cox and David Holmberg

Improved model; editorial and clarity changes. Addressed comments on interaction and service model from TC meetings in May 2010.

1.0 WD 12 2010-05-21 William Cox Editorial and content corrections and updates. Consistency of tone; flagged portions that are more closely related to EMIX.

1.0 WD 13 2010-08-31 Toby Considine Ed Cazalet

Recast to meet new outline, Removed much of the “marketing” content or moved, for now, to appendices. Re-wrote Sections 2, 3. Created placeholders in 4, 5,6 for services definitions.

1.0 WD 14 2010-10-31 William Cox Completed service descriptions and restructured the middle of the document. Completed the EiEvent service and included UML diagrams. Deleted no longer relevant sections.

1.0 WD 15 2010-11-15 William Cox Toby Considine

Re-wrote sections 5, 7. Re-cast and combined to divergent sections 3. Misc Jira responses

1.0 WD 16 2010-11-18 William Cox Added missing Section 6

1.0 WD 17 2010-11-22 Toby Considine, William Cox

Responded to many comments, added Program Services, added description of Resources and EMIX and WS-Calendar (4). Added Glossary



1.0 WD 18 2010-11-24 Toby Considine Responded to formal comments Added additional language on WS-Calendar Incorporated missing ProgramCall Added Simple Market Model to Interactions

1.0 WD 19 2011-02-06 Toby Considine “Clearing the Underbrush” – numerous trivial edits from PR process

1.0 WD20 2011-03-03 Ed Cazalet, Toby Considine

Reorganization of material into new document structure

1.0 WD21 2011-03-06 Ed Cazalet, Toby Considine

Completion of reorganization (transitional material) and repair of all (I hope) links and cross-references

1.0 WD22 2011-03-07 William Cox Toby Considine

Update of UML and Services Repaired documents (links & numbering broken again)

1.0 WD23 2011-05-10 David Holmberg William Cox

Toby Considine

Update to add interaction diagrams, improve text, and add sections on service operation naming, push, and pull.

1769

energy interoperation version 1...william cox 5/11/11 1:20 am deleted: march 3 william cox 5/11/11...

Documents