Specification URIs:

This version:

http://docs.oasis-open.org/energyinterop/ei/v1.0/csprd02/energyinterop-v1.0-csprd02.doc (Authoritative)

http://docs.oasis-open.org/energyinterop/ei/v1.0/csprd02/energyinterop-v1.0-csprd02.html

http://docs.oasis-open.org/energyinterop/ei/v1.0/csprd02/energyinterop-v1.0-csprd02.pdf

Previous version:

http://docs.oasis-open.org/energyinterop/ei/v1.0/csprd01/energyinterop-v1.0-csprd01.doc (Authoritative)

http://docs.oasis-open.org/energyinterop/ei/v1.0/csprd01/energyinterop-v1.0-csprd01.html

http://docs.oasis-open.org/energyinterop/ei/v1.0/csprd01/energyinterop-v1.0-csprd01.pdf

Latest version:

http://docs.oasis-open.org/energyinterop/ei/v1.0/energyinterop-v1.0.doc (Authoritative)

http://docs.oasis-open.org/energyinterop/ei/v1.0/energyinterop-v1.0.html

http://docs.oasis-open.org/energyinterop/ei/v1.0/energyinterop-v1.0.pdf

Technical Committee:

OASIS Energy Interoperation TC

Chairs:

David Holmberg, NIST

William T. Cox

Editor:

Toby Considine, University of North Carolina at Chapel Hill

Related work:

This specification is related to:

.         EMIX V1.0

.         WS-Calendar V1.0

.         NAESB Actors for DR

Other Work Product artifacts:

This prose specification is one component of a Work Product which also includes:

.         XML schemas: ei/v1.0/csprd02/xsd/

Declared XML namespace:

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

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 was last revised or approved by the OASIS Energy Interoperation TC on the above date. The level of approval is also listed above. Check the "Latest version" location noted above for possible later revisions of this document.

Technical Committee members should send comments on this specification to the Technical Committee's email list. Others should send comments to the Technical Committee by using the "Send A Comment" button on the Technical Committee's web page at http://www.oasis-open.org/committees/energyinterop/.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (http://www.oasis-open.org/committees/energyinterop/ipr.php).

Citation format:

When referencing this specification the following citation format should be used:

[ENERGYINTEROP-v1.0]

Energy Interoperation Version 1.0. OASIS Committee Specification Draft 02 / Public Review Draft 02. 15 July 2011. http://docs.oasis-open.org/energyinterop/ei/v1.0/csprd02/energyinterop-v1.0-csprd02.html

 

 

 

Copyright (c) OASIS Open 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.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.

 

1 Introduction. 9

1.1 Terminology. 10

1.2 Normative References 10

1.3 Non-Normative References 10

1.4 Contributions 12

1.5 Namespace. 13

1.6 Naming Conventions 13

1.7 Editing Conventions 14

1.8 Architectural Background. 14

2 Overview of Energy Interoperation. 17

2.1 Scope of Energy Interoperation. 17

2.2 Specific scope statements 17

2.3 Goals & Guidelines for Signals and Price and Product Communication. 17

2.4 Scope of Energy Interoperation Communications 18

2.5 Collaborative Energy [Not Normative] 18

2.6 Assumptions 20

2.6.1 Availability of Interval Metering. 20

2.6.2 Use of EMIX. 20

2.6.3 Use of WS-Calendar 20

2.6.4 Energy Services Interface. 20

3 Energy Interoperation Architecture. 22

3.1 Transactive Energy Interactions 22

3.1.1 Buyer and Seller Party Roles 22

3.1.2 Transactive Interactions and Roles 22

3.1.3 Retail Service Interactions 23

3.1.4 Wholesale Power Interactions 23

3.1.5 Transport Interactions 23

3.2 Event Interactions for Demand and Generation Resources 24

3.2.1 VTN and VEN Party Roles 24

3.2.2 VTN/VEN Interactions 24

3.2.3 VTN/VEN Roles and Services 26

3.2.4 Demand Response Interactions 27

4 Message Composition & Services 29

4.1 WS-Calendar in Energy Interoperation. 29

4.1.1 Schedule Semantics from WS-Calendar (Non-Normative) 29

4.1.2 Simple Sequences in WS-Calendar 30

4.2 EMIX in Energy Interoperation. 31

4.3 Adaptations of WS-Calendar for Energy Interoperation. 31

4.3.1 Simplification of WS-Calendar Schemas 31

4.3.2 Availability and Schedules 32

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

5 Introduction to Services and Operations 34

5.1 Resources, Curtailment, and Generation. 34

5.2 Structure of Energy Interoperation Services and Operations 35

5.3 Narrative Framework for EI Services (Non-Normative) 35

5.4 Naming of Services and Operations 36

5.5 Push and Pull Patterns 36

5.6 Description of the Services and Operations 36

6 Transactive Services 37

6.1 EiRegister Service. 37

6.1.1 Interaction Pattern for the EiRegisterParty Service. 37

6.1.2 Information Model for the EiRegisterParty Service. 38

6.1.3 Operation Payloads for the EiRegisterParty Service. 39

6.2 Pre-Transaction Services 39

6.2.1 Interaction Pattern for the EiTender and EiQuote Services 40

6.2.2 Information Model for the EiTender and EiQuote Services 42

6.2.3 Operation Payloads for the EiTender Service. 43

6.2.4 Operation Payloads for the EiQuote Service. 44

6.3 Transaction Management Services 44

6.3.1 Interaction Patterns for the EiTransaction Service. 45

6.3.2 Information Model for the EiTransaction Service. 45

6.3.3 Operation Payloads for the EiTransaction Service. 46

6.4 Post-Transaction Services 46

6.4.1 Energy Delivery Information. 46

6.4.2 Full Requirements Verification. 47

7 Enroll Service. 48

7.1 Interaction Patterns for the EiEnroll Service. 49

7.2 Information Model for the EiEnroll Service. 50

7.3 Operation Payloads for the EiEnroll Service. 51

8 Event Services 52

8.1 EiEvent Service. 52

8.1.1 Interaction Patterns for the EiEvent Service. 52

8.1.2 Information Model for the EiEvent Service. 53

8.1.3 Operation Payloads for the EiEvent Service. 56

Responses for EiEvent Service Operations 57

8.2 Feedback Service. 58

Interaction Pattern for the EiFeedback Service. 59

8.2.1 Information Model for the EiFeedback Service. 60

Operation Payloads for the EiFeedback Service. 61

8.3 EiEvent Optimizations (Non-Normative) 62

9 Support Services 63

9.1 EiAvail Service. 63

9.1.1 Availability Model 64

9.1.2 Interaction Patterns for the EiAvailability Service. 64

9.1.3 Information Model for the EiAvailability Service. 65

9.1.4 Operation Payloads for the EiAvail Service. 66

9.2 Opt Service. 67

9.2.1 Interaction Patterns for the EiOpt Service. 67

Information Model for the EiOpt Service. 69

9.2.2 Operation Payloads for the EiOpt Service. 70

9.3 Status Service. 71

9.3.1 Interaction Patterns for the EiStatus Service. 71

9.3.2 Information Model for the EiStatus Service. 71

9.3.3 Operation Payloads for the Status Service. 72

10 Market Information. 73

11 Security and Composition [Non-Normative] 75

11.1 Security and Reliability Example. 75

11.2 Composition. 77

11.3 Energy Interoperation and Security. 77

12 Profiles [Normative] 78

12.1 OpenADR [Normative] 78

12.2 TEMIX [Normative] 78

12.3 Price Distribution [Normative] 79

13 Conformance and Processing Rules for Energy Interoperation. 80

13.1 Conformance with the Semantic Models of EMIX and WS-Calendar 80

13.1.1 Recapitulation of Requirements from WS-Calendar and EMIX. 80

13.2 TEMIX Conformance. 81

13.3 Inheritance within Events 81

13.3.1 Sequence Optimization within Events 81

A. Background and Development history. 83

B. Glossary. 85

C. Extensibility in Energy Interoperation. 86

C.1 Extensibility in Enumerated values 86

C.2 Extension of Structured Information Collective Items 86

D. Acknowledgements 88

E. Revision History. 90

 

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

Figure 1‑2: Two-way MEP where after a service is consumed an acknowledgment is provided to the service consumer 15

Figure 1‑3: Callback MEP where a service provider sends an acknowledgement to the service consumer, performs a corresponding activity to act on the service request, then in turn makes a service request to the original initiating service consumer and receiving an acknowledgement in return 16

Figure 3‑1: Parties Interacting with Offers and Transactions as Either Buyers or Sellers. 23

Figure 3‑2: Example DR Interaction One. 24

Figure 3‑3: Example DR Interaction Two. 25

Figure 3‑4: Example DR Interaction Three. 25

Figure 3‑5: Web of Example DR Interactions 25

Figure 3‑6: Service Interactions between a VTN and a VEN. 27

Figure 4‑1: Basic Power Object from EMIX. 30

Figure 4‑2: WS-Calendar Partition, a simple sequence of 5 intervals 30

Figure 4‑3: Applying Basic Power to a Sequence. 31

Figure 4‑4: Simplifying back to Power in a Single Interval 31

Figure 4‑5 A Demand Response Event and associated Signals 32

Figure 6‑1: Interaction Diagram for EiRegister Service. 38

Figure 6‑2: EiParty UML Class Diagram.. 38

Figure 6‑3: UML Class Diagram for EiRegisterParty Service Operation Payloads 39

Figure 6‑4: Interaction Diagram for the EiTender Service. 41

Figure 6‑5: Interaction Diagram for the EiQuote Service. 42

Figure 6‑6: UML Class Diagram for the Operation Payloads for the EiTender Service. 43

Figure 6‑7: UML Class Diagram for the EiQuote Service Operation Payloads 44

Figure 6‑8: Interaction Diagram for the EiTransaction Service. 45

Figure 6‑9: UML Class Diagram of EiTransaction Service Operation Payloads 46

Figure 7‑1: Interaction Diagram for the EiEnroll Service. 50

Figure 7‑2: UML Model for EiEnrollment 51

Figure 8‑1: UML Interaction Diagram for the EiEvent Service Operations 53

Figure 8‑2: UML Class Diagram for EiEventType and Related Classes 54

Figure 8‑3: UML Class Diagram of the EventBaseType which Contains a [WS-Calendar] schedule. 55

Figure 8‑4 UML Class Diagram Showing Details of the Signals for EiEventType. 55

Figure 8‑5: UML Class Diagram for EiEvent Service Operation Payloads 56

Figure 8‑6: Response Values for EiEvent Operation Errors 57

Figure 8‑8‑7: UML Interaction Diagram for the EiFeedback Service Operations 59

Figure 8‑8: UML Class Diagram for the EiFeedback Class 60

Figure 8‑9: UML Class Diagram for EiResponse service operations 61

Figure 8‑10: UML Class Diagram for EiFeedback Service Operation Payloads 62

Figure 9‑1: Interaction Pattern for the EiAvailability Service. 65

Figure 9‑2: UML Class Diagram for the EiAvailability and Associated Classes 65

Figure 9‑3: UML Class Diagram for EiAvailability Service Operation Payloads 66

Figure 9‑4: Interaction Diagram for the EiOpt Service. 68

Figure 9‑5: UML Class Diagram for EiOpt Class 69

Figure 9‑6: UML Class Diagram for EiOpt Service Operation Payloads 70

Figure 9‑7: Interaction Pattern for EiStatusService. 71

Figure 9‑8: UML Class Diagram for EiStatus Service Operation Payloads 72

Figure 10‑1: UML Class Diagram for Market Context 74

Figure 11‑1: Web of Example DR Interactions 75

 

 

Table 1‑1: Namespaces Used in this Specification. 13

Table 3‑1: Interactions and Actors 26

Table3‑2: Demand Response Interaction Pattern Example. 28

Table 4‑1: WS-Calendar defined terms used in Energy Interoperation. 29

Table 6‑1: Register Services 37

Table 6‑2: Pre-Transaction Tender Services 39

Table 6‑3: Pre-Transaction Quote Services 40

Table 6‑4: Transaction Management Services 44

Table 6‑5: Energy Usage Information. 46

Table 7‑1 Enrolling Entity Descriptions 48

Table 7‑2: EiEnroll Service Operations 49

Table 8‑1: Event Services 52

Table 8‑2: Response Values for EiEvent Errors 57

Table 8‑3: Feedback Service. 58

Table 9‑1: Avail Service. 63

Table 9‑2: Opt-Out Service. 67

Table 9‑3: Status Services 71

Table 10‑1: EI Market Context Elements 73

Table 10‑2: EI Market Rule Set 73

Table 11‑1: Interactions and Actors for Security and Reliability Example. 76

Table 12‑1: Services used in OpenADR Profile. 78

Table 12‑2: Services used in TEMIX Profile. 78

Table 12‑3: Services used in Price Distribution Profile. 79

 

 

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

Figure 1‑1: Conceptual model for smart Grid from [NIST] showing communications requirements

Energy Interoperation defines messages to communicate price, reliability, and emergency conditions over communications interfaces. Energy Interoperation is agnostic as to the technology that a communications interface may use to carry these messages.

Energy Interoperation messages can concern real time interactions, forward projections, or historical reporting. Energy Interoperation is intended to support market-based balancing of energy supply and demand while increasing fluidity of transactions. Increased deployment of distributed and intermittent energy sources will require greater fluidity in both wholesale and retail markets. In retail markets, Energy Interoperation is meant to support greater consumer choice as to energy source.

Energy supplies are becoming more volatile due to the introduction of renewable energy sources. The introduction of distributed energy resources may create localized, volatile surpluses and shortages. These changes will create more granular energy transactions, require more granularity in temporal price changes , and more granularity in service territory.

Balancing local energy resources brings more kinds of resources into the mix. Natural gas markets share many characteristics with electricity markets. Local thermal energy distribution systems can balance electricity markets while having their own surpluses and shortages. Nothing in Energy Interoperation restricts its use to electricity-based markets.

Energy consumers will need technologies to manage their local energy supply, including curtailment, storage, generation, and time-of-use load shaping and shifting. In particular, consumers will respond to Energy Interoperation messages for emergency and reliability events, or price messages to take advantage of lower energy costs by deferring or accelerating usage, and to trade curtailment, local generation and energy supply rights. Energy Interoperation does not specify which technologies consumers will use; rather it defines a technology agnostic interface to enable accelerated market development of such technologies.

To balance supply and demand, energy suppliers must be able to schedule resources, manage aggregation, and communicate both the scarcity and surplus of energy supply over time. Suppliers will use Energy Interoperation to inform customers of emergency and reliability events, to trade curtailment and supply of energy, and to provide intermediation services including aggregation of provision, curtailment, and use.

Energy Interoperation relies on standard format for communication of time and interval [WS-Calendar] and for Energy Price and Product Definition [EMIX]. This document assumes that there is a high degree of symmetry of interaction at any Energy Interoperation interface, i.e., that providers and customers may reverse roles during any period.

The OASIS Energy Interoperation Technical Committee is developing this specification in support of the National Institute of Standards and Technology (NIST) Framework and Roadmap for Smart Grid Interoperability Standards, Release 1.0 [Framework] in support of the US Department of Energy (DOE) as described in the Energy Independence and Security Act of 2007 [EISA2007].

Under the Framework and Roadmap, the North American Energy Standards Board (NAESB) surveyed the electricity industry and prepared a consensus statement of requirements and vocabulary. This work was submitted to the Energy Interoperation Committee in April 2010 and subsequently updated and delivered in January 2011.

All examples and all Appendices are non-normative.

1.1 Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [EMIX] OASIS Committee Specification Draft 01, Energy Market Information Exchange 1.0, November 2010. http://docs.oasis-open.org/emix/emix/v1.0/csd01/emix-v1.0-csd01.pdf [RFC2119].

1.2 Normative References

[EMIX] OASIS Committee Specification Draft 01, Energy Market Information Exchange 1.0, November 2010. http://docs.oasis-open.org/emix/emix/v1.0/csd01/emix-v1.0-csd01.pdf [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.

[RFC2246] T. Dierks, C. Allen Transport Layer Security (TLS) Protocol Version 1.0, http://www.ietf.org/rfc/rfc2246.txt, IETF RFC 2246, January 1999.

[SOA-RM] OASIS Standard, Reference Model for Service Oriented Architecture 1.0, October 2006. http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf

[Vavailability] C. Daboo, B. Desruisseaux, Calendar Availability, http://tools.ietf.org/html/draft-daboo-calendar-availability-02, IETF Internet Draft, April 2011

[WS-Calendar] OASIS Committee Specification Draft, WS-Calendar 1.0, September May 201.
http://docs.oasis-open.org/ws-calendar/ws-calendar-spec/v1.0/csprd03/ws-calendar-spec-v1.0-csprd03.pdf

1.3 Non-Normative References

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

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

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

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

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

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

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

[IEC 61968] Application integration at electric utilities - System interfaces for distribution management - Part 9: Interfaces for meter reading and control

[IEC 61970-301] Energy management system application program interface (EMS-API) - Part 301: Common information model (CIM) base

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

[OpenADR] Mary Ann Piette, Girish Ghatikar, Sila Kiliccote, Ed Koch, Dan Hennage, Peter Palensky, and Charles McParland. 2009. Open Automated Demand Response Communications Specification (Version 1.0). California Energy Commission, PIER Program. CEC-500-2009-063. [NAESB-SG] NAESB Smart Grid Subcommittee, http://www.naesb.org/smart_grid_standards_strategies_development.asp

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

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

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

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

[SPML] OASIS Standard, Service Provisioning Markup Language (SPML) v2 - DSML v2 Profile, April 2006. http://www.oasis-open.org/committees/download.php/17708/pstc-spml-2.0-os.zip [TC57CIM] IEC Technical Committee 57 Common Information Model (IEC 61968 and IEC 61970, various dates)

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

[Vavailability] C. Daboo, B. Desruisseaux, Calendar Availability, http://tools.ietf.org/html/draft-daboo-calendar-availability-02, IETF Internet Draft, April 2011

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

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

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

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

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

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

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

1.4 Contributions

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

NAESB Smart Grid Standards Development Subcommittee [NAESB-SG]:

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

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

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

The following documents are under development and subject to change.

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

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

The ISO / RTO Council Smart Grid Standards Project:

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

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

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

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

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

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

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

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

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

UCAIug OpenSG OpenADR Task Force:

OpenADR 1.0 System Requirements Specification v1.0
http://osgug.ucaiug.org/sgsystems/OpenADR/Shared%20Documents/SRS/OpenSG%20OpenADR%201.0%20SRS%20v1.0.pdf

OpenADR 1.0 Service Definition - Common Version :R0.91
http://osgug.ucaiug.org/sgsystems/OpenADR/Shared%20Documents/Services/OpenSG%20OpenADR%20SD%20-%20Common%20r0.91.doc

OpenADR 1.0 Service Definition – Web Services Implementation Profile Version: v0.91 http://osgug.ucaiug.org/sgsystems/OpenADR/Shared%20Documents/Services/OpenSG%20OpenADR%20SD%20-%20WS%20r0.91.doc

1.5 Namespace

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

Dereferencing the above URI will produce the Resource Directory Description Language [RDDL 2.0] document that describes this namespace.

Table 1 lists the XML namespaces that are used in this specification. The choice of any namespace prefix is arbitrary and not semantically significant.

Table 1‑1: Namespaces Used in this Specification

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 the namespace URI specified above.

1.6 Naming Conventions

This specification follows some naming conventions for artifacts defined by the specification, as follows:

For the names of elements and the names of attributes within XSD files, the names follow the lowerCamelCase convention, with all names starting with a lower case letter. For example,

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

For the names of intents, the names follow the lowerCamelCase convention, with all names starting with a lower case letter, EXCEPT for cases where the intent represents an established acronym, in which case the entire name is in upper case.

An example of an intent that is an acronym is the "SOAP" intent.

1.7 Editing Conventions

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

All elements in the tables not marked as "optional" are mandatory.

Information in the "Specification" column of the tables is normative. Information appearing in the note column is explanatory and non-normative.

All sections explicitly noted as examples are informational and are not to be considered normative.

1.8 Architectural Background

Energy Interoperability defines a service-oriented approach to energy interactions. Accordingly, it assumes a certain amount of definitions of roles, names, and interaction patterns. This document relies heavily on roles and interactions as defined in the OASIS Standard Reference Model for Service Oriented Architecture [SOA-RA].

Service orientation focuses on the desired results rather than the requested processes. Service orientation complements loose integration. Service orientation organizes distributed capabilities that may be in different ownership domains.

The SOA paradigm concerns itself with visibility, interaction, and effect. Visibility refers to the capacity for those with needs and those with capabilities to be able to see each other. Interaction is the activity of using a capability. A service provides a decision point for any policies and transactions without delving into the process on either side of the interface

Services are concerned with the public actions of each interoperating system. Service interactions consider private actions, e.g., those on either side of the interface, to be inherently unknowable by other parties. A service is used without needing to know all the details of its implementation. Services are generally paid for results, not effort.

While loosely coupled it is important to understand some typical message exchange patterns to understand how business processes are tied together through an SOA. [SOA-RA] section 4.3.2.1 describes how message exchange patterns (MEP) are leveraged for this purpose. While [SOA-RA] describes two types of MEPs, event notification and request response it also notes that, "This is by no means a complete list of all possible MEPs used for inter- or intra-enterprise messaging".

Three types of MEPs can inform the discussion on energy-interop integration; a one way MEP, which differs somewhat from an event notification MEP in that no response is required from the service provider, although the service consumer may receive appropriate http messages, e.g. 404 error.

Additional a two-way MEP and a callback MEP are specific types of request/request MEPs described in [SOA-RA] that are used in Energy Interoperation. A two way MEP exchange pattern assumes that after a service is consumed an acknowledgement is sent. This acknowledgement is made up of the message header of the returning service, and may include a standardized acknowledgement payload, ie, for capturing errors, (or no errors is the service was called successfully).

Figure 1‑2: Two-way MEP where after a service is consumed an acknowledgment is provided to the service consumer

The callback MEP is similar to the request/response pattern described in [SOA-RA] except that it is more specific. In a callback MEP the service provider will send an acknowledgement upon receiving a request, however, once the service provider completes the corresponding business process, it will become a service consumer, by calling a service of the previous consumer, where it turn it will receive its own acknowledgement.

Figure 1‑3: Callback MEP where a service provider sends an acknowledgement to the service consumer, performs a corresponding activity to act on the service request, then in turn makes a service request to the original initiating service consumer and receiving an acknowledgement in return

Loose integration using the SOA style assumes careful definition of security requirements between partners. Size of transactions, costs of failure to perform, confidentiality agreements, information stewardship, and even changing regulatory requirements can require similar transactions be expressed within quite different security contexts. It is a feature of the SOA approach that security is composed in to meet the specific and evolving needs of different markets and transactions. Security implementation must be free to evolve over time and to support different needs. Energy Interoperation allows for this composition, without prescribing any particular security implementation.

2.1 Scope of Energy Interoperation

Energy Interoperation (EI) supports the following:

.       Transactive energy markets [TEMIX]

.       Distribution of dynamic and contract prices

.       Demand response approaches ranging from dispatch of load resources (with external contractual penalties for non-compliance) to price levels embedded in an event.

.       Measurement and confirmation of response.

EI engages Distributed Energy Resources (DER) while making no assumptions as to their processes or technology.

While this specification supports agreements and transactional obligations, this specification offers flexibility of implementation to support specific programs, regional requirements, and goals of the various participants including the utility industry, aggregators, suppliers, and device manufacturers.

It is not the intent of the Energy Interoperation Technical Committee to imply that any particular agreements are endorsed, proposed, or required in order to implement this specification. Energy market operations are beyond the scope of this specification although the interactions that enable management of the actual delivery and acceptance are within scope. Energy Interoperation defines interfaces for use throughout the transport chain of electricity as well as supporting today's intermediation services and those that may arise tomorrow.

2.2 Specific scope statements

Interaction patterns and service definitions to support the following are in scope for Energy Interoperation:

• Market communications to support transactive energy. (see [TEMIX])
• Specific offerings by end nodes to alter energy use.
• Measurement and confirmation of actions taken, including but not limited to curtailment, generation, and storage, including load and usage information, historical, present, and projected.
• Notifications requesting performance on transactions offered or executed.
• Information models for price and product communication.
• Service definitions for Energy Interoperation

The following are out of scope for Energy Interoperation:

• Requirements specifying the type of agreement, or tariff used by a particular market.
• Validation and verification of performance, except for feedback on curtailment and generation.
• Communication (e.g. transport method) other than Web services to carry the messages from one point to another. The messages specified in Energy Interoperation can be transmitted via a variety of transports.

2.3 Goals & Guidelines for Signals and Price and Product Communication

1. There are at least four market types, and signals and price and product standardization must support all four, while allowing for the key differences that exist and will continue to exist in them. The four market types are:

.       no open wholesale and no retail competition

.       open wholesale market only

.       open retail competition only

.       open wholesale and open retail competition.

2. Wholesale market DR signals and price and product communication have different characteristics than retail market DR signals and price and product communication, although Energy Interoperation defines a commonality in format.
3. It is likely that most end users, with some exceptions among Commercial and Industrial (C&I) customers, will not interact directly with wholesale markets.
4. Retail pricing models are complex, due to the numerous tariff rate structures that exist in both regulated and un-regulated markets. Attempts to standardize DR control and pricing signals must not hinder regulatory changes or market innovations when it comes to future tariff or pricing models.
5. New business entities such as Energy Service Providers (ESP), Demand Response Providers (DRP), DR Aggregators, and Energy Information Service Providers (EISP), will play an increasing role in DR implementation. Energy Interoperation supports these and new as yet unnamed intermediation services.
6. DER may play an increasingly important role in DR, yet the development of tariff and/or pricing models that support DER's role in DR are still in early stages of development.
7. The Customer's perspective and ability to react to DR control and price signals must be a key driver during the development of standards to support DR programs.

In addition, it is the policy of the Energy Interoperation Technical Committee that

8. Where feasible, customer interfaces and the presentation of energy information to the customer should be left in the hands of the market, systems, and product developers enabled by these specifications.

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

2.4 Scope of Energy Interoperation Communications

While the bulk of examples describe the purchase of real power, emerging energy markets must exchange economic information about other time-sensitive services.

For example, delivery of power is often constrained by delivery bottlenecks. The emergence of distributed generation and Plugin Electric Vehicles (PEV) will exacerbate this problem. EMIX includes product definitions for tradable congestion charges and transmission rights. Locational market prices in distribution may come to mirror those already seen in transmission markets.

Other services address the direct effects of distribution congestion, including phase imbalances, voltage violations, overloads, etc.

These markets introduce different market products, yet the roles and interactions remain the same. Intelligent distribution elements, up to an intelligent transformer take roles in these interactions.

A description of the tariffs or market rules to support these interactions is outside the scope of this specification. However, interaction patterns in this specification are defined to provide additional information for markets in which tariffs or market rules are required.

2.5 Collaborative Energy [Not Normative]

Collaborative Energy, in this specification, refers to the transactions and management of energy using collaborative approaches, including but not limited to markets, requests for decrease of net demand, while addressing the business goals of the respective parties in arms-length interactions.

Transactive energy describes the established process of parties buying and selling energy based on tenders (buy or sell offers) that may lead to transactions among parties. In open wholesale forward energy markets, a generator may tender a quantity of energy at a price over a future delivery interval of time to a customer. Acceptance of a tender results in a binding transaction. In some cases, the transaction requires physical delivery of energy. In other cases, the transaction is settled for cash at a price determined by a prescribed price index. The use of Energy Interoperation to enable present and future wholesale and retail energy markets and retail tariffs, including dynamic and multi-part tariffs is described in [TEMIX]. This section reviews the generic roles and interactions of parties involved in energy transactions.

In this specification, the information exchanged and the services needed to implement smart energy are defined.

Today's markets are not necessarily tomorrow's. Today's retail markets have grown up around conflicting market restrictions, tariffs that are contrary to the goals of Collaborative Energy, and historical practices that pre-date automated metering and e-commerce. Today's wholesale market applications, designed, built and deployed in the absence of standards, has resulted in little or no interchangeability among vendor products, complex integration techniques, and duplicated product development. The Technical Committee opted to avoid direct engagement with these problems. Energy Interoperation aims for future flexibility while it addresses the problems of today.

While the focus today is on on-demand load reduction, on-demand load increase is just as critical for Collaborative Energy interactions. Any large component of intermittent energy sources will create temporary surpluses as well as surfeits. Interactions between different smart grids and between smart grids and end nodes must maximize load shifting to reflect changing surpluses or shortages of electricity. Responsibilities and benefits must accrue together to the participants most willing and able to adapt.

The Committee, working with the [EMIX] Technical Committee developed a component model of an idealized market for electricity transactions. This model assumes timely automated interval metering and an e-commerce infrastructure. TEMIX describes electricity in this normal market context. This model was explained in the [TEMIX] paper, an approved work product of the EMIX committee. Using the components in this model, the authors were then able to go back and simulate the market operations of today.

Energy Interoperation supports four essential market activities:

1. There is an indication of interest (trying to find tenders to buy or sell) when a Party is seeking partner Parties for a demand response transaction or for an energy source or sale.
2. There is a tender (offer or bid) to buy or sell a service, e.g. production of energy or curtailment of use.
3. There is an execution of a transaction to purchase or supply, generally caused by the acceptance of a tender.
4. For some transactions, such as Demand Response, there may be a call for performance or delivery of the subject of a transaction at the agreed-upon price, time, and place.

Version 1.0 of Energy Interoperation does not define the critical fifth market activity, measurement and verification (M&V). A NAESB task force (DSM/EE Demand Response Work Group) is continuing work to define the business requirements for M&V.

Other business models may combine services in novel ways. An aggregator can publish an indication of interest to buy curtailment at a given price. A business willing to respond would offer an agreement to shed load for a specific price. The aggregator may accept some or all of these offers. The performance in this case could be called at the same time as the tender acceptance or later.

Communication of price in transactions is at the core of the Energy Interoperation services. Four types of prices are identified in this specification:

1. Priced Offer: a forward offer to buy or sell a quantity of an energy product for a specified future interval of time, the acceptance of which by a counterparty results in a binding agreement. This includes tariff priced offers where the quantity may be limited only by the service connection and DR prices.
2. Ex-Post Price: A price assigned to energy purchased or sold that is calculated or assigned after delivery. Price may be set based on market indices, centralized market clearing, tariff calculation or any other process.
3. Priced Indication of Interest: the same as a Priced Offer except that no binding agreement is immediately intended.
4. Historical Price: A current price, past transaction price, past offered price, and statistics about historical price such as high and low prices, averages and volatility.
5. Price Forecast: A forecast by a party of future prices that are not a Priced Indication of Interest or Priced Offer. The quality of a price forecast will depend on the source and future market conditions

A grid price service is able to answer the following sorts of questions:

1.     What is the price of Electricity now?

2.     What will it be in 5 minutes?

3.     What price will electricity have for each hour of the day tomorrow?

4.     What will it be at other times in the future?

5.     What was the highest price for electricity in the last day? Month? Year?

6.     What was the lowest price for electricity in the last day? Month? Year?

7.     What was the high price for the day the last time it was this hot?

Each answer carries with it varying degrees of certainty. The prices may be fixed by contracts or tariffs that change infrequently if at all. The prices may be fixed tariffs, "unless a DR event is called." The prices may even represent wild guesses about open markets. With a standardized price service, technology providers can develop solutions to help grid operators and grid customers manage their energy use portfolios.

This specification also encompasses Emergency or "Grid Reliability" events. Grid Reliability events require mandatory participation in today's markets. These events are described as standing pre-executed option agreements. A grid operator need merely call for performance as in any other event.

2.6 Assumptions

2.6.1 Availability of Interval Metering

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

2.6.2 Use of EMIX

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

2.6.3 Use of WS-Calendar

This specification uses the OASIS [WS-Calendar] specification to communicate schedules and intervals. WS-Calendar is the standard under the NIST Smart Grid Roadmap for all such communication.

WS-Calendar expresses a general approach to communications of sequences and schedules, and their gradual complete instantiation during the transactive process. Despite its name, WS-Calendar does not require that communications use web services.

2.6.4 Energy Services Interface

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

This work assumes that there is no direct interaction across the ESI.

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

3.1 Transactive Energy Interactions

Transactive Energy is a refers to the communication of prospective and completed transactions of energy whether market-based, bilateral or, contract-, agreement-, or tariff-based, and whether of energy or options on energy. The terminology used by Transactive Energy is most evident today in the buying and selling of wholesale energy in bilateral and exchange transactions. The use of Energy Interoperation to enable present transactive energy interoperation and future markets and dynamic agreements is addressed in the TEMIX Profile (and further described in [TEMIX]). This section reviews the roles and interactions of Parties involved in energy transactions.

3.1.1 Buyer and Seller Party Roles

The Energy Interoperation (EI) architecture describes interactions between two or more actors. Actors may perform in a chain of actors and supporting actors.

The actor for all EI interactions is a Party. An actor is a Party that can take on a number of roles. This terminology follows common business interaction terminology wherein suppliers sell to intermediaries who may buy transport services and sell to end use customers.

A Party can be an end use customer, a generator, a retail service provider, a demand response provider, a marketer, a distribution system operator, a transmission system operator, a system operator such as an ISO or RTO, a microgrid operator, or any party engaging in transactions or supporting transactions for energy.

Parties may participate in many interactions concurrently as well as over time. In theory, any Party can transact with any other Party subject to applicable regulatory restrictions. In practice, markets will establish interactions between Parties based on regulation, convenience, economics, credit, network structure, locations, and other factors.

3.1.2 Transactive Interactions and Roles

A Party can take on two basic roles in transactions:

• Buyer and
• Seller

At any moment, each Party has a position in the market. A Party selling power relative to its current position takes the role of a Seller. A Party buying power relative to its current position takes the role of a Buyer. A generator typically takes the role of a Seller, but can also take on the role of a Buyer. A generator may take the role of a Buyer in order to reduce generation because of a change in generator or market conditions. An end-use customer typically takes the role of a Buyer, but if tendered an attractive price may curtail usage and thereby take the role of a Seller.

A distributed generator certainly can take on the roles of buyer and seller. If a distributed generator sells 2 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 low enough. A distributed storage device takes on the roles of buyer and seller at different times.

Parties taking on the roles of Buyers and Sellers interact both through tenders for transactions and through transactions as illustrated in Error! Reference source not found..

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

If the Tender is a buy offer by B, then when the Tender is accepted by A, A then becomes the Seller and B the Buyer with respect to the new Transaction. Typically, there are [EMIX] Standard Terms for an agreement among parties that facilitates many transactions under the terms of the enabling agreement.

Two parties can also engage in an option transaction. An option is a promise granted by one Party (Option Writer) to a second Party (Option Holder) usually for a premium payment. The Option Holder is granted a right to invoke specific transactions for energy that the Option Writer promises to deliver. Demand response, ancillary services, and price cap transactions are forms of options. Any Party may take the role of a Buyer or Seller of a tender for an option transaction.

Any Party may take the role of a Buyer or Seller of a tender for an option transaction. After an offer of an option is executed, one Party takes the role of Promisor and the other takes the role of Promisee. In the case of a demand response (DR) option, the DR Manager is in the Promisee Role and the DR Participant is in the Promisor Role.

3.1.3 Retail Service Interactions

Retail Customers interact with either tariffed cost-of-service retail providers or competitive retail providers with various service plans. Either way the price of the service must be clearly communicated to the customer. With the introduction of interval metering and dynamic pricing, clear communication of price and the purchasing decisions by customers is essential.

EI provides services to communicate both the tendered prices by retailers to customers and the purchase transaction by customers. Customers with distributed energy resources (DER) or storage may often be a seller to retailer or other parties. Transactions may also include call options on customers by a retailer to reduce deliveries and call options by customers on a retailer to provide price insurance.

3.1.4 Wholesale Power Interactions

Retail Energy Providers, Aggregators, Power Marketers, Brokers, Exchanges, System Operators and Generators all interact in the wholesale market for deliveries on the high voltage transmission grid. Transactions include forward transactions for delivery, near-real time transaction and cash settled futures transactions for hedging risks.

EI mirrors the tender and transaction interaction patterns of open forward wholesale power markets. Near real-time wholesale markets for resources provided by independent system operators are also provided for in EI design with work ongoing.

3.1.5 Transport Interactions

Transmission and Distribution services transport energy from one location to another. Transport is the common term used by EI and EMIX to refer to both Transmission and Distribution. Prices for Transport are dynamic and need careful communication. EI models tenders and transactions for Transport products using the same interactions as for Energy products.

EI makes no assumptions about how prices for Transport are determined.

3.2 Event Interactions for Demand and Generation Resources

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

3.2.1 VTN and VEN Party Roles

Similar to the Party interactions of transactive energy, event interactions also have an interoperation model between two or more Actors or Parties. One designated Actor (for that given interaction) is called the Virtual Top Node (VTN) and the remaining one or more actors are called Virtual End Node(s), or VEN(s).[1].

Parties may participate in many interactions concurrently as well as over time. For example, a particular Actor may participate in multiple Demand Response programs, receive price communication from multiple sources, and may in turn distribute signals to additional sets of Parties.

The VTN / VEN Interactions combine and compose multiple sets of pairwise interactions to implement more complex structures. By using simple pairwise interactions, the computational and business complexity for each set of Parties is limited, but the complexity of the overall interaction is not limited.

3.2.2 VTN/VEN Interactions

In this section, we clarify terminology for roles in VTN/VEN Energy Interoperation interaction patterns. The description and approach is consistent with the Service-Oriented Architecture Reference Model [SOA-RM]. All interactions SHALL be between two or more Parties. The role of a Party as a VTN or VEN only has meaning within the context of a particular service interaction.

At this level of description, we ignore the presence of application level acknowledgement of invocations, as that reliable and confirmed delivery would typically be implemented by composition with [WS-RM], [WS-Reliability], [WS-SecureConversation] or a similar mechanism. For similar reasons, an actual deployment would compose the necessary security, e.g., [WS-Security], [SAML], [XACML], or [WS-SecureConversation]. See Section 11 for a discussion of compositional security.

We also ignore typical push or pull patterns for interactions, which are deferred to later sections.

Figure 3‑2: Example DR Interaction One

In Figure 3‑2, Party A is the VTN with respect to Party B, which acts as the VEN in this interaction. Party C is not a party to this interaction.

Subsequently, as shown Figure 3‑3, Party B may act as the VTN for an interaction with Party C, which is acting as the VEN for interaction two. Party A is not a party to this interaction.

Figure 3‑3: Example DR Interaction Two

Moreover, the directionality and the roles of the interaction can change as shown in Figure 3‑4.

Again, Party A is not a party to this interaction, but now Party C is the VTN and Party B is the VEN.

Figure 3‑4: Example DR Interaction Three

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

Figure 3‑5: Web of Example DR Interactions

In this figure, certain Parties (B, E, and G) act as both VTN and VEN. This directed graph with arrows from VTN to its VENs could model a Reliability DR Event initiated by the Independent System Operator[2] A who would invoke an operation on its second level VTNs B-E, which could be a group of aggregators. The second level VTN B, in turn invokes the same service on its VENs FGH, who may represent their customers or Transactive resources. Those customers might be industrial parks with multiple facilities, real estate developments with multiple tenants, or a company headquarters with facilities in many different geographical areas, who would invoke the same operation on their VENs.

Each interaction can have its own security and reliability composed as needed—the requirements vary for specific interactions.

The following table has sample functional names for selected nodes. (Note: wrt means "with respect to")

Table 3‑1: Interactions and Actors

Label	Structure Role	Possible Actor Names
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

We have defined two structured roles in each interaction, the Virtual Top Node (VTN) and the Virtual End Node (VEN). A VTN has one or more associated VENs.[3]

Considering service interactions for Energy Interoperation, each VTN may invoke services implemented by one or more of its associated VENs, and each VEN may invoke services implemented by its associated VTN.

In later sections we detail abstract services that address common transactions, Demand Response, price distribution, and other use cases.

Figure 3‑6: Service Interactions between a VTN and a VEN

The interacting pairs can be connected into a more complex structure as we showed in Figure 3‑5.

The relationship of one or more VENs to a VTN mirrors common configurations where a VTN (say an aggregator) has many VENs (say its resources under contract) and each VEN works with one VTN for a particular interaction.[4]

Second, as we have seen, each VEN can implement the VTN interface for another interaction.

Third, the pattern is recursive as we showed above in Figure 3‑3 and allows for more complex structures.[5]

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

In some cases the structure graph may permit cycles, in others not.

3.2.4 Demand Response Interactions

In this section we describe the interaction patterns of the services for demand response respectively invoked by an VTN on one or all of its associated VENs and vice versa. Figure 3‑6: above shows the generic interaction pattern; Table3‑2 below is specific to Demand Response Events.

By applying the recursive definitions of VTN and VEN, we will define specific services in the next sections. See Table3‑2 for service names which are defined more fully in the following sections.

The VTN invokes operations on its VENs such as Initiate DR Event and Cancel DR Event, while the VEN invokes operations on its VTN such as Create Tender and Create Feedback.

Note not all DR works this way. A customer may be sent a curtailment tender by the DR provider with a price and then can decide to respond. If the customer has agreed to a capacity payment then there may be a loss of payments if he does not respond.

Table3‑2: Demand Response Interaction Pattern Example

 

At a first glance, Power and Load Management are simple. Turn on generation. Turn off the lights. The price has just doubled. I won't turn on any resource for less than $100.

Energy interoperation addresses transactive energy and event interactions through the repeated use of two other standards, Energy Market Information eXchange (EMIX) and WS-Calendar.

.       EMIX describes price and product for electricity markets.

.       WS-Calendar communicates schedules and sequences of operations.

.       Energy Interoperation uses the vocabulary and information models defined by those specifications to describe many of the services and events that it provides.

4.1 WS-Calendar in Energy Interoperation

WS-Calendar defines how to use the semantics of the enterprise calendar communications standard iCalendar within service communications. Energy Interoperation is conformant with the [WS-Calendar] specification for communicating duration and time to define a Schedule. [WS-Calendar] itself extends the well-known semantics [RFC5545].

WS-Calendar allows for ways to express a related group of time intervals as a sequence. It additionally allows for a way to abstract certain information of related intervals to avoid repetition of such information in every interval of the sequence. This abstraction is called a WS-Calendar Gluon, and it can be related to a group of intervals in a sequence to represent the same common information present in all intervals in a sequence. Gluons can represent interval information such as "duration" that might stay constant over time inside all the intervals in the sequence.

4.1.1 Schedule Semantics from WS-Calendar (Non-Normative)

Without an understanding of certain terms defined in [WS-Calendar], the reader may have difficulty achieving complete understanding of their use in this standard. The table below provides summary descriptions of certain key terms from that specification. Energy Interoperation does not redefine these terms; they are here solely as a convenience to the reader.

Table 4‑1: WS-Calendar defined terms used in Energy Interoperation

WS-Calendar Term	Description
Duration	Duration is the length of an event scheduled using iCalendar or any of its derivatives. The [XCAL] duration is a data type using the string representation defined in the iCalendar ([RFC5545]) Duration.
Interval	The Interval is a single Duration derived from the common calendar Components as defined in iCalendar ([RFC5545]). An Interval is part of a Sequence.
Sequence	A set of Intervals with defined temporal relationships. Sequences may have gaps between Intervals, or even simultaneous activities. A Sequence is re-locatable, i.e., it does not have a specific date and time. A Sequence may consist of a single Interval, and can be scheduled by scheduling that single Interval in that sequence.
Gluon	A Gluon influences the serialization of Intervals in a Sequence, through inheritance and through schedule setting. The Gluon is similar to the Interval, but has no service or schedule effects until applied to an Interval or Sequence.
Artifact	The thing that occurs during an Interval. [WS-Calendar] uses the Artifact as a placeholder. EMIX Product Descriptions populate Schedules as Artifacts inside Intervals.
Link	A reference to an internal object within the same calendar, or an external object in a remote system. The Link is used by one [WS-Calendar] Component to reference another.
Relationship	Links between Components.
Availability	Availability in this specification refers to the Vavailability Component, itself a collection of recurring Availability parameters each of which expresses set of Availability Windows. In this specification, these Windows may indicate when an Interval or Sequence can be Scheduled, or when a partner can be notified, or even when it is cannot be Scheduled.
Inheritance	A pattern by which information in Sequence is completed or modified by information in a Gluon.

Normative descriptions of the terms in the table above are in [WS-Calendar].

4.1.2 Simple Sequences in WS-Calendar

Nearly every response, every event, and every interaction in Energy Interoperation can have a payload that varies over time, i.e., it is described using a sequence of intervals. Many communications, particularly in today's retail market, involve information about or a request for power delivered over a single interval of time. Simplicity and parsimony of expression must coexist with complexity and syntactical richness.

The simplest power description in EMIX is Transactive power. The simplest demand response is to reduce power. The power object in EMIX can include specification of voltage, and Hertz and quality and other features. There are market interactions where each all of those are necessary. Reduced to its simplest, though, the EMIX Power information consists of Power Units and Power Quantity: as in

Figure 4‑1: Basic Power Object from EMIX

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

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

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

 

 

Figure 4‑3: Applying Basic Power to a Sequence

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

Figure 4‑4: Simplifying back to Power in a Single Interval

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

4.2 EMIX in Energy Interoperation

Energy Interoperation makes extensive use of EMIX to define the semantics of Power and Energy Markets.

In [EMIX] Product Descriptions define Energy and Power. Product Descriptions are applied to Sequences to create Schedules. Schedules conform to the inheritance pattern defined in [WS-Calendar] to reduce repetition of these descriptive elements. [EMIX] Products include an entire Schedule along with transactive information. [EMIX] Options use Availability to describe market information for the right to acquire Energy during certain periods at specified Rates. TeMIX defines communications for transactions of energy delivered at specified rates over an specific intervals.

Each of the elements above is associated with a Market Context. A Market Context may be associated with Standard Terms which may define an overriding set of information for products therein. An [EMIX] Schedule can inherit information from the Standard Terms in a Market just as a WS-Calendar Sequence inherits from a Gluon.

Every Energy Interoperation interaction MAY convey an EMIX Type. Often they convey simplified derivations of [EMIX] types that use conformance and inheritance to reduce to a bare minimum, while still using EMIX semantics.

Energy Interoperation defines Parties which enroll Accounts with counter-Parties. Some of those Accounts participate directly in energy transactions, using the Semantics from TEMIX. Others enroll as Resources with certain capabilities. Some of these Resources may share detailed capability and response information with their counter-party using the EMIX Resource semantics.

4.3 Adaptations of WS-Calendar for Energy Interoperation

Using the relation between Gluon and Sequence in WS-Calendar, external information can be applied to Intervals in a Sequence. A Sequence populated with product descriptions is referred to as a Schedule. Because Schedules embody the same calendaring standards used by most business and personal calendaring systems, there is a base of compatibility between such communications and business and personal systems.

4.3.1 Simplification of WS-Calendar Schemas

Most Energy Interoperation sequences are simple and repetitive, and do not require the richness of the WS-Calendar model. The flexible semantics of WS-Calendar add size and complexity. Energy Interoperation defines its own Types that use the semantics of WS-Calendar but with reduced optionality. These begin with simplified Intervals, which are assembled into Sequences. Information elements are conveyed within these Sequences just as they are in EMIX Schedules. These elements inherit from the Transactive headers and Standard Terms of Market Contexts just as they do in EMIX.

4.3.2 Availability and Schedules

The simple component Vavailability is used again and again in Energy Interoperation. Vavailability allows the definition for a bounded period of time a Party may be able to perform some action. Vavailability is used to define windows for Demand Response, to define when during a given day a Party may receive requests, and for expressing the desire of a Party to place or remove services from markets.

4.4 Applying EMIX and WS-Calendar to a Power Event

Consider the event in Figure 4‑5 A Demand Response Event and associated Signals. This event illustrates the potential complexity of marshaling a load response from a VEN, perhaps a commercial building.

Figure 4‑5 A Demand Response Event and associated Signals

Note first that there are two schedules of prices. The price of electricity for the building "bldg price" is rising to more than double its original price of $0.15 during the interval. The price for Electric Vehicles (EV) is fixed at the lower-than-market rate of $0.12, perhaps because public policy is set to encourage their use. Each of those price curves has an EMIX description.

The dispatch level, i.e., the load reduction made by the building, varies over time. This may be tied to building capabilities, or to maintaining essential services for the occupants. It is not important to the VTN why it is constrained, only that it is. Note that these reductions do not line up with the price intervals on the bar above. In this example, the dispatch level is applied to its own WS-Calendar sequence.

Before and after the event, there is a notification period and a recovery period, respectively. These are fixed durations communicated from the VEN to the VTN, which then must respect them in transactions it awards the VEN. These durations are expressed in the EMIX Resource Description provided by the VEN, and reflected in the Power Transaction awarded by the VTN.

In the language described above, this Event contains two Resources and three Schedules. The Resources are the Electric Vehicle and the Building. The Vehicle receives one schedule of Prices. The Building receives two schedules, one dispatch based, and one price based. Both resources are located within the VEN, and any decisions about how to respond to the event are made within the VEN which is the sole point of communication for the VTN.

In the following sections we describe services and operations consistent with [SOA-RM]. For each service operation there is an actor that invokes the service operation and one that provides the service. We have indicated these roles by the table headings Service Consumer for the actor or role that consumes or invokes the service operation named in the Operation column and Service Provider for the actor or role that provides or implements the service operation as named in the Operation column.

This terminology is used through all service definitions presented in this specification.

The column labeled Response Operation lists the name of the service operation invoked as a response. Most operations have a response, excepting primarily those operations that broadcast messages. The roles of Service Consumer and Service Provider are reversed for the Response Operation.

All communication between customer devices and energy service providers is through the ESI.

For transactive services, both buyer and seller will receive tenders (priced offers) of service and possibly make tenders (priced offers) of service.

Any party using Transactive Energy services may own generation or distributed generation or reduce or increase energy from previously transacted energy amounts. These activities are not identified in transactive services. The dispatch of these resources and the use of energy by a party are influenced by tenders between Parties that may result in new Transactions and changes in operations.

The VEN/VTN services provide a characterization of the aggregate resources of a VEN that may be communicated to the VTN; that relationship depends also on the EiMarketContext in which the interactions take place.

The next section describes the role of Resources, Curtailment and Generation. In a transactive approach tendering and prices are used by parties to discover and negotiate transactions that respect the preferences of each party and energy usage, generation, storage and controllability directly available to each party. There is no formal communication of resource characteristics in the transactive approach.

5.1 Resources, Curtailment, and Generation

If the VEN participates in a demand response program or provides distributed energy resources, its ESI is the interface to at least one dispatchable resource (Resource), that is, to a single logical entity. A Resource may or may not expose any fine structure.[6] The Resource terminology and the duality of generation and curtailment are from [EMIX].

Under a demand response program, a Resource is capable of shedding load in response to Demand Response Events, Electricity Price Signals or other system events (e.g. detection of under-frequency). The VTN can query the actual state of a Resource with the EiFeedback service and request ongoing information. The VEN can query the status of the VTN-VEN relationship using the EiStatus service.

Alternatively, a Resource may provide generation in response to similar information. The net effect is the same.

5.2 Structure of Energy Interoperation Services and Operations

Energy Interoperation defines a web services implementation to formally describe the services and interactions, but fully compliant services and operations may be implemented using other technologies.

The services presented in this specification are divided into four broad categories:

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

The structure of each section is a table with the service name, operations, service provider and consumer, and notes in columns.

The services are grouped so that profiles can be defined for purposes such as price distribution, and Demand Response (with the functionality of [OpenADR]). This specification defines three profiles, the OpenADR Profile, the TeMIX (Transactive EMIX) Profile, and the Price Distribution Profile.

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

5.3 Narrative Framework for EI Services (Non-Normative)

The summary that follows provides a narrative guide to aid in understanding key potential uses of the services. It does not define a normative market or application framework. Markets and applications may use some or all of the services defined herein.

A Party first registers with another party and receives a Party ID. Registration establishes an identity and basic contact information. To act as a VEN, an actor may locate one or more potential VTNs and then poll that potential VTN for the Market Contexts that it offers.

Parties in a market MAY issue indications of interest to other registered Parties in the market. A Party may request information from potential VTNs about the Market Contexts that each offers. In response to an indication of interest, one or more parties may offer to serve as a VTN or as a VEN. Some markets MAY have only one potential VTN. Some Parties MAY be constrained to acting solely in the VEN role. Any such market rule and set of roles is outside the scope for this specification.

A Party which wishes to act as a VEN enrolls one or more Accounts with a VTN. During enrollment, an Account is associated a particular market context. An Account may be enrolled as a Resource, and exchange detailed capability information, or it may be enrolled solely as a transactive participant. A VEN can choose to enroll a single Account in multiple market contexts, or with multiple VTNs. An Account enrolled in a Market Context accepts the rules of that Market Context, which may include specific Terms including non-performance penalties. Market and Application rules concerning multiple enrollments are out of scope for this specification.

A VEN identifies its Accounts by Party ID (its own) and Account Name. It is possible to enroll an Account and associate it with no Market Context. The meaning of such an enrollment is determined by market rules which are outside the scope of this specification.

During Enrollment, each Account is associated with one or more schedules. A Market Context may have a schedule for when it is active. An Account may have a schedule when it can respond to requests. A market may offer different terms for day-time and night-time performance. A VEN may require different Terms for work-time and after-hours performance. Enrollment makes no statement about how such Terms are agreed to, but only how the agreement is expressed.

A VEN may Opt to change its availability for performance. It can make permanent, i.e., non-expiring changes to its schedule by re-enrollment. It can Opt-In to add a specific availability schedule to the existing schedule for a discrete time. It may Opt-Out, replacing the current schedule with another for a discrete time.

5.4 Naming of Services and Operations

The naming of services and operations follows a pattern.

Services are named starting with the letters Ei. Capitalization follows the Upper Camel Case convention.

Operations in each service use one or more of the following patterns. The first listed is a fragment of the name of the initial service operation; the second is a fragment of the name of the response message which acknowledges receipt, describes errors, and may pass information back to the invoker of the first operation.

Create—Created An object is created and sent to the other Party

Cancel—Canceled A previously created request is canceled

Request—Sent A request is made for all objects of the specified type previously created and relevant to this VTN-VEN relationship

Distribute An object (such as a price quote, a curtailment or generation request) is created and sent without expectation of response

To construct an operation name for the EiEvent service, "Ei" is concatenated the name fragment (verb) as listed. For example, an operation to cancel an outstanding operation or event is called EiCancelEvent.

The pattern of naming is consistent with current work in the IEC Technical Committee 57 groups responsible for the [TC57CIM].

5.5 Push and Pull Patterns

The Service Operation naming includes application-level acknowledgements, which in nearly every case carry application-level information, and allow for both push and pull of messages. This description applies to both transactive and VTN/VEN interactions as both are performed by Parties taking on various roles.

Push and Pull are with respect to the invoker of the operation. So if a Party produces information that describes a price quote, it can invoke (in the case of Push) an operation to send it to one or more other Parties. In the alternative, each Party (in the case of Pull) can invoke a request for information by polling, or pulling it, another Party respect to a particular relationship or Market Context.

The Pull operation is performed by the Party invoking the Request service operation pattern and fulfilled with a Sent service operation pattern invoked by the receiving Party.

So a series of Push operations from one Party to a counter-Party is analogous to a series of Pull operations from the counter-Party to the Party.

In the VTN-VEN context, a series of Push operations from a VTN to its VENs is analogous to a series of Pull operations from the VEN to its VTN; by examining (e.g.) the absence of an Event that was visible on a previous Pull the VEN can infer that that Event was canceled. The VEN could then send a Canceled service operation as if it had received a Cancel service operation.

One special case is the Distribute pattern, which expects no response to the invoker.

The service quality of the Pull operations (and in particular the load on the VTN from repeated polling) is not in scope for this specification.

5.6 Description of the Services and Operations

Each service is described as follows. In subsections, we will:

.       Describe the service

.       Show the table of operations

.       Show the interaction patterns for the service operations in graphic form

.       Describe the information model using [UML] for key artifacts used by the service

.       Describe the operation payloads using [UML] for each operation

 

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

• Registration—to enable further phases.
• Pre-Transaction —non-binding quotes and binding tenders for transactions.
• Transaction Services—execution and management of transactions including transaction with optionality.
• Post-Transaction—settlement, energy used or demanded, payment, position.

For transactive services, the roles are Parties and Counterparties. For event and resource services, the Parties adopt a VTN or VEN role for interactions. The terminology of this section is that of business agreements: tenders, quotes, and transaction execution and (possibly delayed) performance under an option or DR transaction.

The register services identify the parties for future interactions. This is not the same as (e.g.) a program registration in a demand response context—here, registration can lead to exchange of tenders and quotes, which in turn may lead to a transaction which will determine the VTN and VEN roles of the respective parties.

6.1 EiRegister Service

The EiRegisterParty service operations create a registration for potential Parties in interactions. This is necessary in advance of an actor interacting with other parties in various roles such as VEN, VTN, tenderer, and so forth

Table 6‑1: Register Services

Service	Operation	Response	Service Consumer	Service Provider	Notes
EiRegister	EiRegisterParty	EiRegisteredParty	Party	Party
EiRegister	EiRequestRegistration	EiSendRegistration	Party	Party
EiRegister	EiCancelRegistration	EiCanceledRegistration	Party	Party

 

6.1.1 Interaction Pattern for the EiRegisterParty Service

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

Figure 6‑1: Interaction Diagram for EiRegister Service

6.1.2 Information Model for the EiRegisterParty Service

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

Figure 6‑2: EiParty UML Class Diagram

6.1.3 Operation Payloads for the EiRegisterParty Service

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

Figure 6‑3: UML Class Diagram for EiRegisterParty Service Operation Payloads

6.2 Pre-Transaction Services

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

Price distribution as in what are sometimes called price signals is accomplished using the EiQuote service.

As with other services, a Party MAY inquire from a counterparty what offers the counterparty acknowledges as open by invoking the EiSendTender service to receive the outstanding tenders.

There is no operation to "delete" a quote; when a quote has been canceled the counterparty MAY delete it at any time. To protect against recycled or dangling references, the counterparty SHOULD invalidate any identifier it maintains for the cancelled quote.

Tenders, quotes, and transactions are [EMIX] artifacts, which contain terms such as schedules and prices in varying degrees of specificity or concreteness.

Table 6‑2: Pre-Transaction Tender Services

Service	Operation	Response	Service Consumer	Service Provider	Notes
EiTender	EiCreateTender	EiCreatedTender	Party	Party	And sends the Tender
EiTender	EiRequestTender	EiSentTender	Party	Party	Request outstanding Tenders from the Service Provider that have been sent to the ServiceConsumer
EiTender	EiCancelTender	EiCancelledTender	Party	Party

 

Table 6‑3: Pre-Transaction Quote Services

Service	Operation	Response	Service Consumer	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)

 

6.2.1 Interaction Pattern for the EiTender and EiQuote Services

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

Figure 6‑4: Interaction Diagram for the EiTender Service

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

Figure 6‑5: Interaction Diagram for the EiQuote Service

6.2.2 Information Model for the EiTender and EiQuote Services

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

6.2.3 Operation Payloads for the EiTender Service

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

Figure 6‑6: UML Class Diagram for the Operation Payloads for the EiTender Service

 

6.2.4 Operation Payloads for the EiQuote Service

Figure 6‑7: UML Class Diagram for the EiQuote Service Operation Payloads

6.3 Transaction Management Services

The service operations in this section manage the exchange of transactions. For demand response, the [overarching] agreement is the context in which events and response take place—what is often called a program is identified by the information element programName in the EiProgram service and elsewhere.

There are no EiCancelTransaction or EiChangeTransaction operations. A compensating transaction SHOULD be created to clarify the economic effect of the reversal.[7]

Table 6‑4: Transaction Management Services

Service	Operation	Response	Service Consumer	Service Provider	Notes
EiTransaction	EiCreateTransaction	EiCreatedTransaction	Party	Party	And send Transaction
EiTransaction	EiRequestTransaction	EiSentTransaction	Party	Party

6.3.1 Interaction Patterns for the EiTransaction Service

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

Figure 6‑8: Interaction Diagram for the EiTransaction Service

6.3.2 Information Model for the EiTransaction Service

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

6.3.3 Operation Payloads for the EiTransaction Service

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

Figure 6‑9: UML Class Diagram of EiTransaction Service Operation Payloads

6.4 Post-Transaction Services

In a market of pure transactive energy, verification would be solely a function of meter readings. The seed standard for smart grid meter readings is the NAESB Energy Usage Information [NAESB EUI] specification.

In today's markets, with most customers on Full Requirements tariffs, the situation is necessarily more complex. Full Requirements describes the situation where purchases are not committed in advance. The seller is generally obligated to provide all that the buyer requires. Full requirements tariffs create much of the variance in today's DR markets.

These sections will apply the [NAESB EUI] along with [WS-Calendar].The [NAESB M&V] Business Practice is also relevant. This entire section is TBD.

6.4.1 Energy Delivery Information

NOTE THIS SERVICE NEEDS UPDATE

These operations create, change, and allow exchange of Energy Usage Information. TBD pending ratification of [NAESB EUI]

Table 6‑5: Energy Usage Information

Service	Operation	Response	Service Consumer	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

 

6.4.1.1 Interaction Pattern for the EiUsage Service

6.4.1.2 Information Model for the EiUsage Service

6.4.1.3 Operation Payloads for the EiUsage Service

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

6.4.2 Full Requirements Verification

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

6.4.2.1 Interaction Patterns for the Full Requirements Verification Service

6.4.2.2 Information Model for the Full Requirements Verification Service

6.4.2.3 Operation Payloads for the Full Requirements Verification Service

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

To enroll a Resource or a Service Provider is distinct from registering a Party—the former identifies and establishes an actor or a Resource with the VTN; the latter identifies a Party which is preparing to interact with other Parties in a transactive manner (and without regard to the VTN/VEN graph but with respect to a market or markets).

The service operations EiRejectEnroll, EiRejectEnrollQualify, and EiAcceptEnroll may be optional in certain deployments.

The entities described in the following table can be enrolled. These are described in the [UML] diagrams as concrete classes that inherit from the EnrollingEntity class. The strings are used to describe the entity; the standard approach to extensibility where a prefix of "x-" indicates an extension SHALL be used.

The types of entity used may depend on the implementation. All implementations SHALL support Resources.

NOTE: Enrollment should include mySchedule and the Market Context Availability.

Table 7‑1 Enrolling Entity Descriptions

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

 

 

Table 7‑2: EiEnroll Service Operations

Service	Operation	Response	Service Consumer	Service Provider	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

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

Figure 7‑1: Interaction Diagram for the EiEnroll Service

7.2 Information Model for the EiEnroll Service

The EiEnroll service has an abstract class for the respective types. The abstract class also has the entity identifier, type (as a string), and name.

The standard values for the type are listed in Table 9-1 Enrolling Entity Descriptions.

Other values MAY be used but MUST be prefixed by "x-" as described in Appendix C

Figure 7‑2: UML Model for EiEnrollment

7.3 Operation Payloads for the EiEnroll Service

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

PENDING

8.1 EiEvent Service

The Event Service is used to call for performance under a transaction. The service parameters and event information distinguish different types of events. Event types include reliability events, emergency events, and more—and events MAY be defined for other actions under a transaction. For transactive services, two parties may enter into a call option. Invocation of the call option by the Promissee on the Promissor can be thought of as raising an event. But typically the Promissee may raise the event at its discretion as long as the call is within the terms of the call option transaction.

An ISO that has awarded an ancillary services transaction to a party may issue dispatch orders, which can also be viewed as events. In this standard, what is sometimes called a price event is communicated using the EiSendQuote operation (see 6.2 "Pre-Transaction Services").

Table 8‑1: Event Services

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 Language [UML] diagrams for the EiEvent class and for each of the operation payloads.

8.1.1 Interaction Patterns for the EiEvent Service

This is the [UML] interaction diagram for the EiEvent Service.

Figure 8‑1: UML Interaction Diagram for the EiEvent Service Operations

 

8.1.2 Information Model for the EiEvent Service

The key class is EiEvent, which has associations with the classes Location, EventInfo, Sequence (from [WS-Calendar], and Program. See Figure 8‑2: below.

An event has certain information including

• A schedule (and a reference to the schedule)—attributes schedule and scheduleGluonRef.(Note: a Schedule includes 1 or more intervals, each of which could have a different program level, price, or whatever other information is being communicated by this Event.)
• An identifier for the event—eventID
• The program or agreement under which the event was issued—program
• A modification counter, a timestamp for the most recent modification, and a reason—modificationNumber, modificationDateTime, and modificationReason
• A location to which the event applies—location—which may be a geospatial location [OGC], an address [UBL], or grid electrical coordinates.
• Baseline value and a timestamp for that value, used to compare curtailment and "normal" usage—energyBaselineValue and energyBaselineTimestamp
• Information on status, comments, and other information—notificationAcknowledgement, operatingDay, performanceComment, reportingInterval, responseValue, status, and vtnComment

 

Figure 8‑2: UML Class Diagram for EiEventType and Related Classes

The EventBaseType classes inherit from a class that includes a [WS-Calendar] VcalendarType element which holds the components of a schedule.

Figure 8‑3: UML Class Diagram of the EventBaseType which Contains a [WS-Calendar] schedule

The SignalInformationBaseType inherits from the [WS-Calendar] ArtifactBaseType, which permits extensions of SignalInformationBaseType to be attached to Intervals in the Schedule contained in EventBaseType. Details of the signals in the EiEventType Figure are shown here.

Figure 8‑4 UML Class Diagram Showing Details of the Signals for EiEventType

8.1.3 Operation Payloads for the EiEvent Service

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

Figure 8‑5: UML Class Diagram for EiEvent Service Operation Payloads

Responses for EiEvent Service Operations

The following table summarizes the values in the EiResponseType artifacts. See Figure (MOVE EARLIER)

Figure 8‑6: Response Values for EiEvent Operation Errors

Table 8‑2: Response Values for EiEvent Errors

Service Operation	Response	Error Specifics	Response Description	Response Term Errors	Notes
EiCreateEvent	Success
	Failure	createdTime	Event past current time
		createdTime	Invalid time indication
		EiEventType	Event already exists		Event malformation not addressed here
All	Failure	Any ID type	No Such ID
All	Failure	Any MRID	No such MRID
All	Failure	ServiceArea	Not in geographic area

 

8.2 Feedback Service

Feedback communicates information about the state of a Resource as it responds to an EiEvent. This is distinct from Status, which communicates information about the state of the Events themselves. See Section 9.3 "Status Service" for a discussion of Status.

EiFeedback operations are independent of EiEvent operations in that they can be requested at any time independent of the status or history of EiEvents.

EiFeedback operations can be timed by setting the mesurementDuration to the desired period for measurement, and the reportDuration to the desired duration between reports; records of type PowerFeedbackType or of type EnergyFeedbackType are available; the type EventDescriptionBaseType MAY be extended to additional implementation-defined types of feedback.

Table 8‑3: Feedback Service

Service	Operation	Response	Service Consumer	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

 

Interaction Pattern for the EiFeedback Service

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

Figure 8‑8‑7: UML Interaction Diagram for the EiFeedback Service Operations

 

8.2.1 Information Model for the EiFeedback Service

EiFeedback is requested by the VTN and supplied by the VEN(s) with respect to Resources with which the VEN is associated and a specific Market Context.

Figure 8‑8: UML Class Diagram for the EiFeedback Class

Operation Payloads for the EiFeedback Service

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

The diagram for Feedback payloads follows the EiResponseSchedule payloads.

Figure 8‑9: UML Class Diagram for EiResponse service operations

 

Figure 8‑10: UML Class Diagram for EiFeedback Service Operation Payloads

8.3 EiEvent Optimizations (Non-Normative)

To limit bandwidth and compact information exchanged, the Technical Committee is working on two related techniques:

a.     factoring out duplicative information

b.     defining conformance so that a restricted language is conveyed

An example of (a) is the Time Zone Identifier and Currency Code - most markets take place in a single time zone and with a single currency; under those assumptions that information can be factored out and need not appear in each interval.

An example of (b) is support for factoring out -- the inheritance mechanism for WS-Calendar and EMIX can be extended by conformance for Energy Interoperation, allowing the factoring to fit in smoothly with the already existing inheritance conformance mechanisms.

This work will be completed shortly after the second Public Review is completed, and will be available in Working Drafts on the Technical Committee Document Archives.

Users of [OpenADR] found that they needed to be able to constrain the application of remote DR services. For The DR Operator, advanced knowledge of these constraints improved the ability to predict results. The services in this schedule are based on the services used to tailor expectations in [OpenADR].

Availability and Opt are similar in that they communicate when a Party will receive an Event or participate in a transactive market. Availability is a long term schedule for when a Party will consider a response. Availability is are set at registration or transaction negotiation. Opt (as in opt in or opt out) encompasses short-term additions to or replacement of the schedule in Availability.

The combination of Availability and Opt states together (a logical or) define the committed response from the VEN.

Availability and Opt apply to curtailment and DER interactions, and only indirectly to price distribution interactions.

9.1 EiAvail Service

The Availability[8] is set by the VEN and indicates when an event may or may not be accepted and executed by the VEN with respect to a Market Context. Knowing the Availability (and Opt information) for its VENs help the VTN estimate response to an event or request.

Availability is a long-term description and may be complex.

When Availability is set, opting in or out does not affect the Availability except for the specific interval(s) defined by the Opt—opting out is temporary unavailability, which may have transaction consequences if an event is created during the optout period.

The modeling for Availability includes behavior indications for the situation where an EiEvent overlaps a constrained time interval.

EiAvailability describes only the available times, using the patterns defined in [WS-Calendar] and [Vavailability]

Table 9‑1: Avail Service

Service	Operation	Response	Service Consumer	Service Provider	Notes
EiAvail	EiCreateAvail	EiCreatedAvail	VEN	VTN
EiAvail	EiChangeAvail	EiChangedAvail	VEN	VTN
EiAvail	EiDeleteAvail	EiDeletedAvail	VEN	VTN
EiAvail	EiRequestAvail	EiSentAvail	VEN	VTN	To ensure that the VTN Availability recorded matches the VEN description or for recovery

The class EiAvailBehavior defines how an issued EiEvent that conflicts with the current EiAvail is performed:

• ACCEPT – accept the issued EiEvent regardless of conflicts with the EiAvail
• REJECT – reject any EiEvent whose schedule conflicts with the EiAvail
• FORCE – regardless of what the issued DR events parameters are (even if there is no conflict) force them to be the parameters that were configured as part of the program.[9]
• RESTRICT – modify the EiEvent parameters so that they fall within the bounds of the EiAvail

9.1.1 Availability Model

This Availability and OptIn and OptOut, as well as Market Rules, use the VavailabilityType defined in [WS-Calendar] which in turn is an XML serialization of [Vavailability]. The semantics are defined in the latter specification.

The behavior of the specified Availability schedule is defined as follows. We call the parameter passed for OptIn and OptOut the Opt Availability.

.       The EiAvail class describes when the VEN expects to be available to respond to a request for performance, generally an EiEvent

.       OptIn and OptOut MUST use one or more Opt Availability defined with concrete fully specified intervals with no recursion

.       The act of Opting in or out affects the overall Availability only during the specific period identified in the envelope defining the OptIn or OptOut schedule.

.       OptIn adds the contents of the VavailabilityType to the available times for the VEN with respect to a MarketContext

.       Availability schedules SHALL be overridden by any OptOut Availability where defined

.       OptOut replaces the contents of the Availability In the Intervals defined in the OptOut Schedule

In short, OptIn adds the Availability intervals' content to the overall VEN Availability; OptOut replaces the entire Intervals with the contents of the OptOut Schedule.

9.1.2 Interaction Patterns for the EiAvailability Service

This is the [UML] interaction diagram for the EiAvail Service.

Figure 9‑1: Interaction Pattern for the EiAvailability Service

 

9.1.3 Information Model for the EiAvailability Service

Figure 9‑2: UML Class Diagram for the EiAvailability and Associated Classes

 

9.1.4 Operation Payloads for the EiAvail Service

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

Figure 9‑3: UML Class Diagram for EiAvailability Service Operation Payloads

 

9.2 Opt Service

The Opt service creates and communicates Opt In and Opt Out schedules from the VEN to the VTN. Schedules are combined with EiAvailability and the Market Context requirements to give a complete picture of the willingness of the VEN to respond to EiEvents received by the VEN.

Exactly one of Opt Out and Opt In schedules MAY be provided. If both are provided, Opt In SHALL be used.

Opt schedules SHALL override any Availability in place while there is an Opt in effect. See [SECTION ON MODEL FOR AVAILABILITY]

Table 9‑2: Opt-Out Service

Service	Operation	Response	Service Consumer	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

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

Figure 9‑4: Interaction Diagram for the EiOpt Service

Information Model for the EiOpt Service

Opting in or out is a temporary situation indicating that the VEN will or will not respond to a particular event or in a specific time period, without changing the potentially complex Availability. The EiOpt schedule is a [WS-Calendar] VavailabilityType.

Figure 9‑5: UML Class Diagram for EiOpt Class

 

9.2.2 Operation Payloads for the EiOpt Service

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

Figure 9‑6: UML Class Diagram for EiOpt Service Operation Payloads

9.3 Status Service

Status communicates information about the state of an Event itself. This is distinct from Feedback which communicates information about the state of Resources as it responds to a DR Event signal. See Section 8.2 Feedback Service for a discussion of Feedback.

This service requests information held by the VTN.

Table 9‑3: Status Services

Service	Operation	Response	Service Consumer	Service Provider		Notes
EiStatus	EiRequestStatus	EiSentStatus	VEN		VTN	Status of outstanding Events known by the VTN

 

9.3.1 Interaction Patterns for the EiStatus Service

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

Figure 9‑7: Interaction Pattern for EiStatusService

9.3.2 Information Model for the EiStatus Service

The EiStatus service operations use the EiEventType.

9.3.3 Operation Payloads for the Status Service

The [UML] class diagram describes the payloads for the EiStatus service operations. The EiEventType top level complexType is shown, without the related types.

Figure 9‑8: UML Class Diagram for EiStatus Service Operation Payloads

 

Each Event and Service in Energy Interoperation take place in a Market Context. This Context defines the behaviors that that each Party can expect from the other.

10.1 The Market Context

Nearly everything in the Market Context is optional. If it is expressed in the Market Context, then it is inherited by all Events and Signals that reference that Context as per the rules in Section 13 Conformance and Processing Rules for Energy Interoperation.

In any market context, there are standing terms and expectations about product offerings. If these standing terms and expectations are not known, many exchanges need to occur of products that do not meet those expectations. If those expectations are only known by local knowledge, then then national and international products need to be re-configured for each local market that they enter. If all market information is transmitted in every information exchange, messages based on EMIX would be repetitious.

Table 10‑1: EI Market Context Elements

Market Context Element	Description
Envelope Contents	Envelope Contents are defined in EMIX as Warrants about extrinsic properties of a product, i.e., the Source, Environmental Characteristics, and other aspects of as Product or Program that may change the value that they buyer attaches to that product.
Event Schedules	Some Markets may operate only defined schedules. For example, some Tariffs specify Demand Response events only during summer afternoons. If the Market Context limits the times that this product is available, it is expressed in the Event Schedules.
Market Context	A URI as defined in [EMIX].
Market Name	A text description of a Market that may be displayed in a user interface.
Expectations	A set of Rule Sets that describe the behaviors and performance expected of Parties in this Context.

Market Contexts are used to express market information that rarely changes once, and thereafter not need to communicate it with each message.

10.2 Overview of Rule Sets

Rule Sets express the Market Performance Rules, or Terms within a Market Context.

Table 10‑2: EI Market Rule Set

Rule Set Element	Description
Terms	A collection of [EMIX] Terms.
Availability	A Schedule during which this Rule Set is active.
Purpose	Enumeration describing how this Rule Set MUST be interpreted.
Rule Set	A can have one or more sets of standard [EMIX] Terms that define participant expectations. One reason there may be more than one Rule Set is that there may be different Terms based on the time of day.

Normative descriptions of the terms in the table above are in [WS-Calendar].

10.3 UML Overview of Market Context

Figure 10‑1: UML Class Diagram for Market Context

 

In this section, we describe the enterprise software approach to security and composition as applied to this Energy Interoperation specification.

Service orientation has driven a great simplification of interoperation, wherein software is no longer based on Application Programming Interfaces (APIs) but is based on exchange of information in a defined pattern of services and service operations [SOA-RM].

The approach for enterprise software has evolved to defining key services and information to be exchanged, without definitively specifying how to communicate with services and how to exchange information—there are many requirements for distributed applications in many environments that cannot be taken into account in a service and information standard. To make such choices is the realm of other standards for specific areas of practice, and even there due care must be taken to avoid creating a monoculture of security.[10]

11.1 Security and Reliability Example

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

Figure 11‑1: Web of Example DR Interactions

We specifically model a Reliability DR Event initiated by the Independent System Operator[11] A, who sends a reliability event to its first-level aggregators B through E. Aggregator B, in turn invokes the same service on its customers (say real estate landlords) F, G, and H.

Those customers might be industrial parks with multiple facilities, real estate developments with multiple tenants, or a company headquarters with facilities in many different geographical areas, which would invoke the same operation on their VENs.

For our example, say that G is a big-box store regional headquarters and I, J, and L are their stores in the affected area.

Each interaction will have its own security and reliability composed as needed—the requirements vary for specific interactions. For example

*       For service operations between A to B, typical implementations include secure private frame-relay networks with guaranteed high reliability and known latency. In addition, rather than relying on the highly reliable network, in this case A requires an acknowledgment message from B back to A proving that the message was received.

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

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

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

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

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

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

So for a simple Demand Response event distribution, we have potentially four different security profiles

The following table has sample functional names for selected nodes.

Table 11‑1: Interactions and Actors for Security and Reliability Example

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

(Note: wrt means "with respect to")

11.2 Composition

In state-of-the art software architecture, we have moved away from monolithic implementations and standards to ones that are composed of smaller parts. This allows the substitution of a functionally similar technology where needed, innovation in place, and innovation across possible solutions.

In the rich ecosystem of service and applications in use today, we compose or (loosely) assemble applications rather than craft them as one large thing. See for example OASIS Service Component Architecture [OASIS SCA], which addresses the assembly, substitution, and independent evolution of components.

A typical web browser or email system uses many standards from many sources, and has evolved rapidly to accommodate new requirements by being structured to allow substitution. The set of standards (information, service, or messaging) is said to be composed to perform the task of delivery of email. Rather than creating a single application that does everything, perhaps in its own specific way, we can use components of code, of standards, and of protocols to achieve our goal. This is much more efficient to produce and evolve than large integrated applications such as older customized email systems.

In a similar manner, we say we compose the required security into the applications—say an aspect of OASIS [WS-Security] and OASIS Security Access Markup Language [SAML]—and further compose the required reliability, say by using OASIS [WS-ReliableMessaging] or perhaps the reliable messaging supported in an Enterprise Service Bus that we have deployed.

A service specification, with specific information to be exchanged, can take advantage of and be used in many different business environments without locking some in and locking some out, a great benefit to flexibility, adoption, and re-use.

11.3 Energy Interoperation and Security

In this section we describe some specific technologies and standards in our palette for building a secure and reliable implementation of Energy Interoperation. Since Energy Interoperation defines only the core information exchanges and services, and other technologies are composed in, there is no optionality related to security or reliability required or present in Energy Interoperation.

The information model in Energy Interoperation 1.0 is just that—an information model without security requirements. Each implementation must determine the security needs (outside the scope of this standard) broadly defined, including privacy (see e.g. OASIS Privacy Management Reference Model [ref]), identity (see e.g. OASIS Identity in the Cloud, OAISIS Key Management Inteoperability, OASIS Enterprise Key Management Infrastructure, OASIS Provisioning Services, OASIS Web Services Federation TC, OASIS Web Services Secure Exchange and more)

Energy Interoperation defines services together with service operations, as is now best practice in enterprise software. The message payloads are defined as information models, and include such artifacts as Energy Market Information Exchange [EMIX] price and product definition, tenders, and transactions, the EiEvent artifacts defined in this specification, and all information required to be exchanged for price distribution, program event distribution, demand response, and distributed energy resources.

This allows the composition and use of required interoperation standards without restriction, drawing from a palette of available standards, best practices, and technologies. The requirements to be addressed for a deployment are system issues and out of scope for this specification.

As in other software areas, if a particular approach is commonly used a separate standard (or standardized profile) may be created. In this way, WS-SecureConversation composes WS-Reliability and WS-Security.

So Energy Inteoperation defines the exchanged information, the services and operations, and as a matter of scope and broad use does not address any specific application as the security, privacy, performance, and reliability needs cannot be encompassed in one specification. Many of the TCs named above have produced OASIS Standards,

(SEE http://www.oasis-open.org/committees/tc_cat.php?cat=security)

These sections define the three normative profiles that are part of Energy Interoperation 1.0.

A profile includes a selection of interfaces, services, and options for a particular purpose.

12.1 OpenADR [Normative]

The OpenADR Profile defines the services required to implement functionality similar to that in [OpenADR]. The inclusion of the Energy Interoperation structure of VTNs and VENs, as well as use of the Energy Market Information Exchange [EMIX] cross-cutting price and product definition standard and WS-Calendar [WS-Calendar] based on the IETF [iCalendar] RFC updates and gives a broader range of applicability in what has been described as the OpenADR 2 Profile.

We present in simplified tabular form the Energy Interoperation services required as part of the OpenADR Profile. When a service is included, all of the listed operations are required, so we list only the service name and the section of this document.

Table 12‑1: Services used in OpenADR Profile

Service	Section	Notes
EiRegisterParty	6.1	Register to identify and receive information
EiQuote	6.2	EiDistributeQuote for distributing dynamic prices (push), other operations for pull including block and tier tariff communication
EiEvent	8	The core event functions and information models
EiFeedback	8.2	The ability to set periodic or one-time information on the state of a Resource
EiAvail	9.1	Constraints on the possible time a Resources is available or not
EiOpt	9.2	Overrides the EiAvail; addresses short-term changes in availability
EiStatus	9.3	Determine status of pending and active events

 

12.2 TEMIX [Normative]

The Tranactive EMIX (TEMIX) Profile defines the services required to implement functionality for energy market interactions.

We present in simplified tabular form the Energy Interoperation services required as part of the TEMIX Profile. When a service is included, all of the listed operations are required, so we list only the service name and the section of this document.

Table 12‑2: Services used in TEMIX Profile

Service	Section	Notes
EiRegisterParty	6.1	Register to identify and receive information
EiQuote	6.2	EiDistributeQuote for distributing dynamic prices (push), other components for pull
EiTender	6.2	The basic offer of agreement is called a tender
EiTransaction	6.3	The core services to reach agreement

 

12.3 Price Distribution [Normative]

The OpenADR Profile defines the services required to implement functionality similar to that in [OpenADR]. The inclusion of the Energy Interoperation structure of VTNs and VENs, as well as use of the Energy Market Information Exchange [EMIX] cross-cutting price and product definition standard and WS-Calendar [WS-Calendar] based on the IETF [iCalendar] RFC updates and gives a broader range of applicability in what has been described as the OpenADR 2 Profile.

We present in simplified tabular form the Energy Interoperation services required as part of the OpenADR Profile. When a service is included, all of the listed operations are required, so we list only the service name and the section of this document.

Table 12‑3: Services used in Price Distribution Profile

Service	Section	Notes
EiRegisterParty	6.1	Register to identify and receive information
EiQuote	6.2	EiDistributeQuote for distributing dynamic prices (push), other components for pull

 

13.1 Conformance with the Semantic Models of EMIX and WS-Calendar

This section specifies conformance with the semantic models of [EMIX] and [WS-Calendar]. Energy Interoperation is strongly dependent on each of these information models.

[WS-Calendar] is a general specification and makes no assumptions about how its information model is used. [WS-Calendar] has specific rules which define Inheritance as a means to reduce the transmission of repetitive information. As this specification constrains schedule communications to specific business interactions, these inheritance rules are extended to embrace rules of interaction and rules of process that further reduce the information that must be expressed in each interval.

Implementations of Energy Interoperation SHALL follow [WS-Calendar] and [EMIX] Conformance rules. These rules include the following conformance types:

• Conformance to the inheritance rules in [WS-Calendar], including the direction of inheritance
• Specific attributes for each type that MUST or MUST NOT be inherited.
• Conformance rules that Referencing Specifications MUST follow
• Description of Covarying attributes with respect to the Reference Specification
• Semantic Conformance for the information within the Artifacts exchanged.
• Conformance to the inheritance rules in [EMIX], including inheritance of Product Definitions and Standard Terms.

Energy Interoperation implementations also use the EMIX Products and Resources also extend the Inheritance patterns of [WS-Calendar] as specified in the EMIX information model. We address each of these in the following sections.

13.1.1 Recapitulation of Requirements from WS-Calendar and EMIX

[WS-Calendar] uses the term Sequence to refer to one or more Intervals with Temporal Relations defined between them that may inherit from zero or more Gluons. [EMIX] introduced the term Schedule to refer to Product Descriptions applied to a Sequence.

13.1.1.1 Specific Attribute Inheritance within Schedules

The rules that define inheritance, including direction in [WS-Calendar], are recapitulated.

I1: Proximity Rule Within a given lineage, inheritance is evaluated though each Parent to the Child before what the Child bequeaths is evaluated.

I2: Direction Rule Intervals MAY inherit attributes from the nearest Gluon subject to the Proximity Rule and Override Rule, provided those attributes are defined as Inheritable.

I3: Override Rule If and only if there is no value for a given attribute of a Gluon or Interval, that Gluon or Interval SHALL inherit the value for that attribute from its nearest Ancestor in conformance to the Proximity Rule.

I4: Comparison Rule Two Sequences are equivalent if a comparison of the respective Intervals succeeds as if each Sequence were fully Bound and redundant Gluons are removed.

I5: Designated Interval Inheritance [To facilitate composition of Sequences] the Designated Interval in the ultimate Ancestor of a Gluon is the Designated Interval of the composed Sequence. Special conformance rules for Designated Intervals apply only to the Interval linked from the Designator Gluon.

I6: Start Time Inheritance When a start time is specified through inheritance, that start time is inherited only by the Designated Interval; the start time of all other Intervals are computed through the durations and temporal; relationships within the Sequence. The designated Interval is the Interval whose parent is at the end of the lineage.

13.1.1.2 Time Zone Specification

The time zone MUST be explicitly expressed in any conforming EMIX Artifact.

This may be accomplished in two ways:

.       The time, date, or date and time MUST be specified using [ISO8601] utc-time (also called zulu time)

.       The [WS-Calendar] Time Zone Identifier, TZID, MUST be in the Lineage of the artifact, as extended by the Market Context. See Section 13.2 below.

If neither expression is included, the Artifact does not conform to this specification and its attempted use in information exchanges MUST result in an error condition.

13.1.1.3 Specific Rules for Optimizing Inheritance

If the Designated Interval in a Series has a Price only, all Intervals in the Sequence have a Price only and there is no Price in the Product.

1.     If the Designated Interval in a Series has a Quantity only, all Intervals in the Sequence have a Quantity only and there is no quantity in the Product.

2.     If the Designated Interval in a Series has a Price & Quantity, all Intervals in the Sequence MUST have a Price and Quantity and there is neither Price not Quantity in the Product.

13.2 TEMIX Conformance

The TeMIX Profile MUST apply the conformance rules for TeMIX described in [EMIX].

13.3 Inheritance within Events

For purposes of processing, inheritance, and conformance, Signal Information is treated as an [EMIX] Product Description, applied to a Sequence, and the Event Base and a Sequence are considered as an [EMIX] Schedule.

Signals within an Event arrive in a setting established by a Market Context. Within an event, there may be multiple Signal types. For purposes of inheritance, An Event may include multiple Event Base derived information elements each with an associated Schedule. For purposes of processing, the Event Base is treated as a [WS-Calendar Gluon], and the Signal Information in each Interval in the Sequence inherits from the Event Base.

Each Event Base specifies a Market Context. If that Market Context is associated with Standard Terms, then those Terms enter the Lineage of the Schedule and are inherited by each Interval. Standard Terms associated with a Market Context enter the Lineage of the Schedule as if the Standard Terms were a Gluon. Product Description, TZID, Program Definition, Terms, et al. can be inherited in this way.

13.3.1 Sequence Optimization within Events

WS-Calendar specifies that each Interval have a unique identifier (UID). WS-Calendar further specifies that each Interval include a Temporal Relation, either direct or transitive, with all other Intervals in a Sequence. A Temporal Relation consists of the Relationship, the UID of the related Interval, and the optional Gap between Intervals.

Within a Market Signal, the UID for each Interval is constructed by concatenating the Signal Identifier, the account identifier (which includes the VEN Party ID), and a sequence number. Within a single Market Signal, this UID can be expressed within each interval by the sequence number alone.

Many Sequences communicated within a Market Signal consist of consecutive intervals without an intervening Gap, which [WS-Calendar] terms a Partition. If the Designated Interval in a Sequence within a Market Signal omits a Temporal Relationship, then no Intervals in the Sequence MAY have a Temporal Relation. Such intervals are sorted by increasing Sequence number (expressed in the UID), and each Interval contains an implied FinishToStart relation to the next Interval with a Gap of zero duration.

Partitions expressed in this way contain only a Sequence Number, the Duration of the Interval, and the Market Signal Payload. The effect of this is that Event Intervals are ordered as a Partition in order of increasing sequence.

There is a significant disconnect between customer load and the value of energy. The demand is not sensitive to supply constraints; the load is not elastic; and the market fails to govern consumer behavior. In particular, poor communications concerning high costs at times of peak use cause economic loss to energy suppliers and consumers. There are today a limited number of high demand periods (roughly ten days a year, and only a portion of those days) when the failure to manage peak demand causes immense costs to the provider of energy; and, if the demand cannot be met, expensive degradations of service to the consumer of energy.

As the proportion of alternative energies on the grid rises, and more energy comes from intermittent sources, the frequency and scale of these problems will increase and there will be an increasing need for 24/7 coordination of supply and demand. In addition, new electric loads such as electric vehicles will increase the need for electricity and with new load characteristics and timing.

Energy consumers can use a variety of technologies and strategies to shift energy use to times of lower demand as well as to reduce use during peak periods. This shifting and reduction can reduce the need for new power plants, and transmission and distribution systems. These changes will reduce the overall costs of energy through greater economic efficiency. This process is known by various names, including load shaping, demand shaping, and demand response (DR). Consistent interfaces and messages for DR is a high priority cross-cutting issue identified in the NIST Smart Grid Interoperability Roadmap.

Distributed energy resources, including generation and storage, now challenge the traditional hierarchical relationship of supplier and consumer. Alternative and renewable energy sources may be located closer to the end nodes of the grid than traditional bulk generation, or even within the end nodes. Wind and solar generation, as well as industrial co-generation, allow end nodes to sometimes supply. Energy storage, including mobile storage in plug-in hybrid vehicles, means that even a device may be sometimes a supplier, sometime a customer. As these sources are all intermittent, they increase the challenge of coordinating supply and demand to maintain the reliability of the electric grid. These resource, with their associated issues, are generally named distributed energy resources (DER). The NIST Smart Grid Interoperability Roadmap, this specification, and [EMIX] see a continuum between DR and DER.

Better communication of energy prices addresses growing needs for lower-carbon, lower-energy buildings, net zero-energy systems, and supply-demand integration that take advantage of dynamic pricing. Local generation and local storage require that the consumer (in today's situation) make investments in technology and infrastructure including electric charging and thermal storage systems. People, buildings, businesses and the power grid will benefit from automated and timely communication of energy prices, capacity information, and other grid information.

Consistency of interface for interoperation and standardization of data communication will allow essentially the same model to work for homes, small businesses, commercial buildings, office parks, neighborhood grids, and industrial facilities, simplifying interoperation across the broad range of energy providers, distributors, and consumers, and reducing costs for implementation.

These communications will involve energy consumers, producers, transmission systems, and distribution systems. They must enable aggregation of production, consumption, and curtailment resources. These communications must support market makers, such as Independent System Operators (ISOs), utilities, and other evolving mechanisms while maintaining interoperation as the Smart Grid evolves. On the consumer side of these interfaces, building and facility agents will be able to make decisions on energy sale, purchase, and use that fit the goals and requirements of their home, business, or industrial facility.

The new symmetry of energy interactions demands symmetry of interaction. A net consumer of energy may be a producer when the sun is shining, the wind is blowing, or an industrial facility is cogenerating[12]. Each interface must support symmetry as well, with energy and economic transactions able to flow each way.

Energy Interoperation defines the market interactions between smart grids and their end nodes (Customers), including Smart Buildings and Facilities, Enterprises, Industry, Homes, and Vehicles. Market interactions are defined here to include all informational communications and to exclude direct process control communications. This document defines signals to communicate interoperable dynamic price, reliability, and emergency signals to meet business and energy needs, and scale, using a variety of communication technologies.

No definition in this glossary supplants normative definitions in this or other specifications. They are here merely to provide a guidepost for readers at to terms and their special uses. Implementers will want to be familiar with all referenced standards.

Agreement is broad context that incorporates market context and programs. Agreement definitions are out of scope in Energy Interoperation.

DR Resource: see Resource.

EMIX: As used in this document, EMIX objects are descriptions applied to a WS-Calendar Sequence. EMIX defines Resource capabilities, used in tenders to match capabilities to need, and in Products, used in tenders and in specific performance and execution calls.

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

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

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

Status: Information about an Event, perhaps in relation to a specific Resource.

Sequence: A set of temporally related intervals with a common relation to some informational artifact as defined in WS-Calendar. Time invariant elements are in the artifact (known as a gluon) and time-varying elements are in each interval.

Tender: A tender is an offering for a Transaction. See Transaction.

Transaction: A binding commitment between parties entered into under an agreement.

VEN – see Virtual End Node

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

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

VTN – see Virtual Top Node

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

C.1 Extensibility in Enumerated values

EI defines a number of enumerations. Some of these, such as measurements of power, are predictably stable. Others, such as market contracts or energy sources, may well have new elements added. In general, these accept any string beginning with "x-" as a legal extension. In particular, these are defined using the following mechanism in the formal schemas (XSD's).

In ei.xsd, the extensibility pattern is defined. This pattern look like:

<xs:simpleType name="EiExtensionType">

<xs:annotation>

<xs:documentation>Pattern used for extending string enumeration, where allowed</xs:documentation>

</xs:annotation>

<xs:restriction base="xs:string">

<xs:pattern value="x-\S.*"/>

</xs:restriction>

</xs:simpleType>

Non-extensible enumerated types look like this:

<xs:simpleType name="VoltageUnitsType">

<xs:restriction base="xs:string">

<xs:enumeration value="MV"/>

<xs:enumeration value="KV"/>

<xs:enumeration value="V"/>

</xs:restriction>

</xs:simpleType>

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

<xs:simpleType name="MeasurementProtocolType">

<xs:union memberTypes="power:MeasurementProtocolEnumeratedType emix:EmixExtensionType"/>

</xs:simpleType>

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

C.2 Extension of Structured Information Collective Items

EI anticipates adding some information structures that are more complex than simple strings can be extended as well. A challenge for these items is that they are more complicated and so require formal definition. Formal definitions, expressed as additions to schema, could require changes to the specification. Without formal definition, it is difficult for trading partners to agree on valid messages.

EI uses abstract classes for many information exchanges. For example, trading partners could agree on the exchange of larger or smaller lists of quality measures. Many measures of power quality are defined in power-quality.xsd. Quality consists of an array of elements that are derived from the abstract base quality element.

<xs:complexType name="PowerQualityType">

<xs:annotation>

<xs:documentation>Power Quality consists of a number of measures, based on contract, negotiation, and local regulation. Extend Power Quality to incorporate new elements by creating additional elements based on PowerQualityBaseType</xs:documentation>

</xs:annotation>

<xs:sequence>

<xs:element name="measurementProtocol" type="power:MeasurementProtocolType"/>

<xs:element name="constraints" type="power:ArrayOfPowerQualities"/>

</xs:sequence>

</xs:complexType>

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

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

and the type extends the abstract base class BasePowerQualityMeaurementType:

<xs:complexType name="SupplyVoltageVariationsType" mixed="false">

<xs:complexContent mixed="false">

<xs:extension base="power:BasePowerQualityMeasurementType">

<xs:sequence>

<xs:element name="count" type="xs:int"/>

</xs:sequence>

</xs:extension>

</xs:complexContent>

</xs:complexType>

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

 

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

Participants:

Hans Aanesen, Individual

Bruce Bartell, Southern California Edison

Timothy Bennett, Drummond Group Inc.

Carl Besaw, Southern California Edison

Anto Budiardjo, Clasma Events, Inc.

Edward Cazalet, Individual

Joon-Young Choi, Jeonju University

Kevin Colmer, California Independent System Operator

Toby Considine, University of North Carolina

William Cox, Individual

Sean Crimmins, California Independent System Operator

Phil Davis, Schneider Electric

Sharon Dinges, Trane

Robert Dolin, Echelon Corporation

Rik Drummond, Drummond Group Inc.

Ernst Eder, LonMark International

Thomas Ferrentino, Individual

Craig Gemmill, Tridium, Inc.

Girish Ghatikar, Lawrence Berkeley National Laboratory

Gerald Gray, Southern California Edison

Anne Hendry, Individual

Thomas Herbst, Cisco Systems, Inc.

David Holmberg, NIST

Gale Horst, Electric Power Research Institute (EPRI)

Ali Ipakchi, Open Access Technology International Inc. (OATi)

Oliver Johnson, Tendril Networks, Inc.

Sila Kiliccote, Lawrence Berkeley National Laboratory

Ed Koch, Akuacom Inc

Michel Kohanim, Universal Devices, Inc.

Larry Lackey, TIBCO Software Inc.

Derek Lasalle, JPMorganChase

Jeremy Laundergan, Southern California Edison

Benoit Lepeuple, LonMark International

Edgardo Luzcando, Midwest ISO and ISO/RTO Council (IRC)

Carl Mattocks, Individual

Dirk Mahling, CPower

Kyle Meadors, Drummond Group Inc.

Scott Neumann, Utility Integration Solutions Inc.

Robert Old, Siemens AG

Mary Ann Piette, Lawrence Berkeley National Laboratory

Donna Pratt, New York ISO and ISO/RTO Council (IRC)

Ruchi Rajasekhar, Midwest Independent System Operator

Jeremy Roberts, LonMark International

Anno Scholten, Individual

Pornsak Songkakul, Siemens AG

Jane Snowdon, IBM

Aaron Snyder, NIST

William Stocker, New York ISO and ISO/RTO Council (IRC)

Pornsak Songkakul, Siemens AG

Robert Stayton, Individual

Jake Thompson, EnerNOC

Matt Wakefield, Electric Power Research Institute (EPRI)

Douglas Walker, California Independent System Operator

Evan Wallace, NIST

Dave Watson, Lawrence Berkeley National Laboratory

David Wilson, Trane

Leighton Wolffe, Individual

Brian Zink, New York Independent System Operator

The Technical Committee also acknowledges the work of the contributing groups who did so much to bring requirements and use cases to the attention of the Committee. In particular, the ISO/RTO Council task force on Demand Response, the UCAIug OpenSG Task Force on OpenADR, and the NAESB Smart Grid Task Force provided invaluable guidance and frequent feedback.

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

UCAIug OpenSG OpenADR Task Force:

Albert Chiu, Pacific Gas & Electric

Bruce Bartell, Southern California Edison

Gerald Gray, Southern California Edison

 

The ISO / RTO Council Smart Grid Standards Project:

We want to thank the IRC team, in particular those who directly participated in this Technical Committee:

Edgardo Luzcando, Midwest ISO and ISO/RTO Council (IRC)

Donna Pratt, New York ISO and ISO/RTO Council (IRC)

William Stocker, New York ISO and ISO/RTO Council (IRC)

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

 

NAESB Smart Grid Standards Development Subcommittee Co-chairs:

Brent Hodges, Reliant

Robert Burke, ISO New England

Wayne Longcore, Consumers Energy

Joe Zhou, Xtensible Solutions

 

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 03		Toby Considine
1.0 WD 04		Toby Considine
1.0 WD 05		Toby Considine
1.0 WD 06		Toby Considine
1.0 WD 07		Toby Considine
1.0 WD 08	2010-03-09	Toby Considine	Reduced core functions to two service groups, transactive 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 Program Call 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.
1.0 WD24	2011-06-28	William Cox Toby Considine	Updates to EiEvent, EiOpt, EiAvail, EiFeedbak, EiStatus. Deleted EiProgram. Updated model, schemas, and diagrams.
1.0 WD25	2011-07-04	Toby Considine William Cox	Numerous Jira issues, new schemas, new UML,
1/0 WD26	2011-07-08	Toby Considine	No changes to Spec, updated schemas to refer to EMIX PR03