Description: oasis

Energy Interoperation Version 1.0

Committee Specification Draft 01

26 November 2010

Specification URIs:

This Version: (Authoritative)

Previous Version:


Latest Version:

Technical Committee:

OASIS Energy Interoperation TC


David Holmberg

William T. Cox


Toby Considine

Related work:

This specification is related to:

·         EMIX V1.0

·         WS-Calendar V1.0

·         NAESB Actors for DR

Declared XML Namespace(s):


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, 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 will coordinate 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.


This document was last revised or approved by the Energy Interoperation Technical Committee on the above date. The level of approval is also listed above. Check the “Latest Version” or “Latest Approved 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

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 (

Citation Format:

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

ENERGYINTEROP-v1.0       OASIS Committee Specification Draft 01, Energy Interoperation Version 1.0, November 2010.


Copyright © OASIS® 2010. 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.


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 names "OASIS" and “EnergyInterop” are trademarks 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 for above guidance.

Table of Contents

1        Introduction. 6

1.1 Terminology. 7

1.2 Normative References. 7

1.3 Non-Normative References. 7

1.4 Contributions. 8

1.5 Naming Conventions. 9

1.6 Architectural References. 10

2        Overview of Energy Interoperation. 11

2.1 Scope of Energy Interoperation. 11

2.2 Goals & Guidelines for Signals and Price and Product Communication. 11

2.2.1 Specific scope statements. 12

2.3 Background & Approach [Not Normative] 12

2.4 Assumptions. 13

2.4.1 Availability of Interval Metering. 13

2.4.2 Use of EMIX. 14

2.4.3 Use of WS-Calendar 14

2.4.4 Energy Services Interface. 14

3        Energy Interoperation Architecture. 15

3.1 Structure of Actors, Roles and Interactions. 15

3.1.1 Transactive Roles and Interactions. 15

3.1.2 Option Transaction Roles and Interactions. 16

3.2 Demand Response and Resource Dispatch Interactions. 17

3.2.1 Sample Interaction Patterns. 18

3.2.2 Roles and Services. 19

3.2.3 Services and Demand Response Interaction Patterns. 20

4        Message Composition & Services. 22

4.1 WS-Calendar in Energy Interop. 22

4.1.1 Simple Sequences in WS-Calendar 22

4.2 EMIX and Energy Interop. 23

4.3 Using Gluons to Define Contracts. 24

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

4.5 Introduction to Services. 25

5        Security and Composition [Non-Normative] 27

5.1 Security and Reliability Example. 27

5.2 Composition. 28

5.3 Energy Interoperation and Security. 29

6        Energy Interoperation Services. 30

7        Transactive Services. 31

7.1.1 Information Model for the EiRegisterParty Service. 31

7.1.2 Operation Payloads for the EiRegisterParty Service. 32

7.2 Pre-Contract Services. 32

7.2.1 Information Model for the EiTender and EiQuote Service. 33

7.2.2 Operation Payloads for the EiTender Service. 34

7.2.3 Operation Payloads for the EiQuote Service. 35

7.3 Contract Management Services. 35

7.3.1 Information Model for the EiContract Service. 36

7.3.2 Operation Payloads for the EiContract Service. 36

7.4 Post-Contract Services. 37

7.4.1 Energy Usage Information. 37

7.4.2 Full Requirements Verification. 37

8        Event Services. 38

8.1 EiEvent Service. 38

8.1.1 Information Model for the EiEvent Service. 38

8.1.2 Operation Payloads for the EiEvent Service. 40

8.2 Feedback Service. 41

8.2.1 Information Model for the EiFeedback Service. 41

8.2.2 Operation Payloads for the EiFeedback Service. 42

8.3 EiProgram Service. 42

8.3.1 Information Model for the EiProgram Service. 44

8.3.2 Operation Payloads for the EiProgram Service. 45

9        Support Services. 46

9.1 EiConstraint Service. 46

9.1.1 Information Model for the Constraint Service. 47

9.1.2 Operation Payloads for the EiConstraint Service. 48

9.2 Opt Out Service. 48

9.2.1 Information Model for the Opt Out Service. 49

9.2.2 Operation Payloads for the Opt Out Service. 50

9.3 Status Service. 51

9.3.1 Information Model for the Status Service. 51

9.3.2 Operation Payloads for the Status Service. 51

10      Conformance. 52

A.      Background and Development history. 53

B.      Collaborative Energy. 55

B.1 Collaborative Energy in Residences. 55

B.2 Collaborative Energy in Commercial Buildings. 55

B.3 Collaborative Energy in Industry. 55

B.4 Summary of Collaborative Energy. 56

C.      Glossary. 57

D.      Acknowledgements. 58

E.      Revision History. 60

1      Introduction

Energy Interoperation defines information exchanges and services to coordinate energy supply and use, including power and ancillary services, between any two parties such as energy suppliers and customers, markets and service providers indicated 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 arrows that represent communications, but is not limited to those interactions.

Figure 1‑1: Representative Communications for Energy Interoperation

Energy Interoperation defines messages to communicate price, reliability, and emergency conditions. These communications 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 contracts. Increasing 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. Energy supply margins are becoming smaller. The introduction of distributed energy resources may create localized surpluses and shortages. These changes will create more granular energy markets, more granular in temporal changes in price, and more granular in 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 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.

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 [RFC2119].

1.2 Normative References

[RFC2119]               S. Bradner, Key words for use in RFCs to Indicate Requirement Levels,, IETF RFC 2119, March 1997.

[RFC2246]               T. Dierks, C. Allen Transport Layer Security (TLS) Protocol Version 1.0,, IETF RFC 2246, January 1999.

[SOA-RM]               OASIS Standard, Reference Model for Service Oriented Architecture 1.0, October 2006.

[EMIX]                    OASIS Committee Specification Draft 01, Energy Market Information Exchange 1.0, November 2010.

[WS-Calendar]        OASIS Committee Specification Draft, WS-Calendar 1.0, September 2010.

1.3 Non-Normative References

[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.

[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.

[EISA2007]             Energy Independence and Security Act of 2007,

[Framework]           National Institute of Standards and Technology, NIST Framework and Roadmap for Smart Grid Interoperability Standards, Release 1.0, January 2010,

[Galvin]                  Galvin Electricity Initiative, Perfect Power,

[ID-CLOUD]             OASIS Identity in the Cloud Technical Committee

[KMIP]                    OASIS Standard, Key Management Interoperability Protocol Specification Version 1.0, October 2010

[SAML]                   OASIS Standard, Security Assertion Markup Language 2.0, March 2005.

[OASIS SCA]          OASIS Service Component Architecture Member Section

[OASIS PMRM]       OASIS Privacy Management Reference Model (PMRM) Technical Committee, 

[SPML]                   OASIS Standard, Service Provisioning Markup Language (SPML) v2 - DSML v2 Profile, April 2006.

[SOA-RA]                OASIS Public Review Draft 01, Reference Architecture for Service Oriented Architecture Version 1.0, April 2008

[TEMIX]                  OASIS Working Draft, Transactional Energy White Paper, May 2010.

[WS-Addr]              Web Services Addressing (WS-Addressing) 1.0, W3C Recommendation,

[WSFED]                OASIS Standard, Web Services Federation Language (WS-Federation) Version 1.2, 01 May 2009

[WSRM]                  OASIS Standard, WS-Reliable Messaging 1.1, November 2004.

[WS-SecureConversation]   OASIS Standard, WS-SecureConversation 1.3, March 2007.

[WS-Security]         OASIS Standard, WS-Security 2004 1.1, February 2006.

[WS-SX]                 OASIS Web Services Secure Exchange (WS-SX) Technical Committee

[XACML]                 OASIS Standard, eXtensible Access Control Markup Language 2.0, February 2005.

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:

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

[NAESB EUI]          NAESB REQ Energy Usage Information Model: 

[NAESB EUI]          NAESB WEQ Energy Usage Information Model:

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:  

[NAESB PAP 09]     Phase Two Requirements Specification for Retail Standard DR Signals – for NIST PAP09:

The ISO / RTO Council Smart Grid Standards Project:

Information Model – HTML:

Information Model – EAP:

XML Schemas:

Eclipse CIMTool Project:

Interactions - Enrollment and Qualification:

Interactions - Scheduling and Award Notification:

Interactions - Deployment and Real Time Notifications:

Interactions - Measurement and Performance:

Interactions Non-Functional Requirements:

UCAIug OpenSG OpenADR Task Force:

Need definitive and permanent links here     

1.5 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,

<element name="componentType" type="energyinterop:type-componentType"/>

For the names of intents, the names follow the UpperCamelCase convention, with all names starting with an upper 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.6 Architectural References

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.

Service orientation refers to an integration approach that focuses on the desired results rather than the requested processes [SOA-RA]. Service orientation complements loose integration. Service orientation organizes distributed capabilities that may be in different ownership domains.

Visibility, interaction, and effect are key concepts for describing the SOA paradigm. 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 contracts without delving into the process on either side of the interface

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

2      Overview of Energy Interoperation

2.1 Scope of Energy Interoperation

Energy Interoperation (EI) supports transactive energy [TEMIX]. EI also supports demand response approaches ranging from limited direct load control to override-able suggestions to customers. EI includes measurement and verification of curtailment. EI engages Distributed Energy Resources (DER) while making no assumptions as to their processes or technology.

While this specification supports agreements and contractual 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 contractual obligations 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 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.

  1. 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.
  2. It is likely that most end users, with some exceptions among Commercial and Industrial (C&I) customers, will not interact directly with wholesale market.
  3. 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.
  4. New business entities such as Energy Service Providers (ESP), Demand Response Providers (DRP), DR Aggregators, and Energy Information Service Providers (ESIP), will play an increasing role in DR implementation. Energy Interoperation supports these and new as yet unnamed intermediation services.
  5. 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.
  6. The Customer’s perspective and ability to react to DR control and pricing 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

  1. 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 [REFERENCE] provided guidance on the DR 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 definitions, especially, relied on the documents developed to support the NAESB effort in the wholesale [IRC] and retail [OpenSG] markets.

2.2.1 Specific scope statements

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

The following are out of scope for Energy Interoperation:

2.3 Background & Approach [Not Normative]

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 smart 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 resulting 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. While 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 smart 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 contract 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 contract (transaction to purchase / supply) generally caused by the acceptance of a tender.

4.     For some contracts, such as Demand Response, there may be a call for performance of a contract 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 is currently (December 2010) defining the business requirements for M&V.

Other business models may combine services in novel ways. An aggregator can publish an indication of interest in to buy curtailment at a given price. A business willing to respond would offer a 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 is at the core all of the Energy Interoperation services. We identify four types of prices:

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 contracted 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 pricing 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 was the highest price for electricity in the last day? Month? Year?

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

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

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

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

Each answer carries with it varying degrees of certainty. The prices may be fixed tariffs absolutely locked down. The prices may be fixed tariffs, “unless a DR event is called.” The prices may be 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.

Emergency or "Grid Reliability" events are also encompassed by this approach. Grid Reliability events require mandatory participation in today’s markets. These can be described as standing pre-executed option contracts. A grid operator then need merely call for performance as in any other event.

2.4 Assumptions

2.4.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.4.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.4.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 contracts. Despite its name, WS-Calendar does not require that communications use web services.

2.4.4 Energy Services Interface

The Energy Services Interface (ESI) is the external face of the energy management systems in the end node. The ESI facilitates the communications among the entities (e.g. utilities, ISOs) that produce and distribute electricity and 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.

3      Energy Interoperation Architecture

This section provides an overview of the interaction structure, and defines the roles and actors in electricity markets. Later sections will define the interactions more carefully as services.

3.1 Structure of Actors, Roles and Interactions

The Energy Interoperation (EI) architecture views interoperation as taking place in the context of an interaction 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.1 Transactive Roles and Interactions

A Party can take on two basic roles:

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 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 Figure 2.

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. The term transaction and contract are used interchangeably in this document. Typically, an Agreement (or Program) will be an enabling agreement among many parties that facilitates many contracts under the terms of the enabling Agreement.

3.1.2 Option Transaction Roles and Interactions

Two parties can also engage in option transactions. An option is a promise granted by the first Party (Promisor) to the second Party (Promisee) usually for some consideration. The Promisee is granted a right to invoke specific transactions (operations) that the Promisor promises to perform. Demand response, ancillary services, and energy option transactions are forms of options.

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. These roles of Parties and interactions among them are illustrated in Figure 3:


Figure 3‑2: Option Roles and Interactions

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.

Figure 3‑2 illustrates a more general terminology for both Demand Response and for third party resource dispatch: the role of Promisor is called the Virtual Top Node (VTN) and the role of Promisee is called the Virtual End Node (VEN).

Informally and interchangeably we will write that a Party implements the role of Buyer or Seller. But a Buyer and Seller of options such as demand response options may also implement the roles of VTN and VEN for that interaction.

Interoperation between a VTN and VEN has several steps as shown in Figure 3‑2. Typically a VEN communicates its capabilities and status to a VTN. At some point, an invocation event caused a VTN to invoke a service on the VEN. The VEN then responds by scheduling a transaction that when executed results in a delivery of energy services.

3.2 Demand Response and Resource Dispatch Interactions

The Energy Interoperation architecture views interoperation taking place in the context of an interaction between two or more actors, where one designated actor is (for that given interaction) called Virtual Top Node (VTN) and the remaining one or more actors are called Virtual End Node(s) [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.

Energy Interoperation combines and composes 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.1 Sample Interaction Patterns

In this section, we clarify terminology for roles in 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 acknowledgement are typically implemented by composing with [WS-RM], [WS-Reliability], [WS-SecureConversation] or a similar mechanism. For similar reasons, an actual deployment would compose in the necessary security, e.g., [WS-Security], [SAML], [XACML], or [WS-SecureConversation].

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

Figure 3‑3: Example DR Interaction One

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

Subsequently, as shown in Figure 4, 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 for a party to interaction two in Figure 3‑3:.

Figure 3‑4 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‑5: 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 as shown in Figure 3‑6:

Figure 3‑6: 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 contracted 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.


Table 3—1: Interactions and Actors


Structure Role

Possible Actor Names



System Operator, DR Event Initiator, Microgrid controller, landlord


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

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


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

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


VEN (wrt G and wrt E)

Microgrid element, floor, HVAC unit, machine


3.2.2 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‑7: 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‑6.

The relationship of one or more VENs to a VTN mirrors common configurations where a VTN (say an aggregator) has many VENs (say its contracted resources) 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‑6: 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.3 Services and Demand Response Interaction Patterns

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. Error! Reference source not found. above shows the generic interaction pattern; Figure 3‑7: 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 Figure 3‑8: 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 Submit DR Standing Bid and Set DR Event 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, As shown below, standing bids do not require an event notification, only a notification of acceptance.

Figure 3‑8: Demand Response Interaction Pattern Example

4      Message Composition & Services

At initial 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 these issues 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. Together these describe the complexity of the services and events that are provided by Energy Interoperation.

4.1 WS-Calendar in Energy Interop

WS-Calendar describes how service delivery changes over time. WS-Calendar is based upon the enterprise calendar communications standard iCalendar. WS-Calendar simplifies the essential appointment of iCalendar into the interval. Each interval is able to hold an artifact from another space, say a DR event or power quantity and price. Intervals are then built up, one after the other, into sequences.

WS-Calendar includes elements to express schedules and gaps and parallel interactions using sequences. While this complexity is available to the practitioner, it is not required in implementation.

WS-Calendar is used by EMIX to define Products, i.e., services in contracts, from EMIX Product Descriptions, which are described below. WS-Calendar is also used directly in a number of Energy Interoperation interfaces, whenever a service communicates a schedule for service delivery.

WS-Calendar is also used to describe other schedule-related aspects of Energy markets. For example, reserve generation may be on call only on summer afternoons on weekdays. Some tariffs may specify that Demand Response events are available only on a similar schedule. This can be hard to describe de novo. It is a common use of iCalendar to schedule a meeting for Mondays and Wednesdays for the next two months. Because WS-Calendar is derived from iCalendar, it is able to express this availability, which in Energy Interop we call Business Schedules, easily and completely.

WS-Calendar gluons associate with intervals in a sequence and share information with them. Gluons can control the start time and duration of intervals in a sequence. Gluons can contain the same artifacts as do intervals. A complex artifact may be shared between Gluon and each Interval in a sequence, so that invariant information is expressed only once, in the Gluon, and the information that changes over time, perhaps price or quantity, is the only part of the Artifact in each interval.

To fully understand the expressiveness of [WS-Calendar], one should read that specification.

4.1.1 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. Even so, most communications, particularly in today’s retail market, involve information about or a request for a single interval. Simplicity and parsimony of expression must coexist with complexity and syntactical richness.

The simplest power description, in EMIX is transactional 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 interactions, these messages look like Figure 4—4, simple and compact. When an information element is more complex, and varies over time, it may expand as in Figure 4—3. But in all cases, DR Events, Price Quotes, or Program Calls, the essential message is an Information object applied to a WS-Calendar sequence.

4.2 EMIX and Energy Interop

EMIX provides price and product definitions for electricity markets. EMIX elements are closely aligned with the Market Interfaces as defined in the [CIM]. EMIX specifies Power Options and Power Products by applying Product Descriptions to WS-Calendar Sequences. Product Descriptions are shared as Artifacts across Sequences, wherein the invariant information expressed only in the Gluon, and the information that changes over time, perhaps price, or quantity, in each interval.

EMIX describes Reserves using the language of market Options, whether they are spinning reserves, on call to provide power, or are demand responsive load, ready to reduce use upon request. EMIX Options describe the contract to stand ready, expressed as a business schedule. EMIX Options defines the potential size of the response that can be called. The EMIX Option includes a warranted response time. Finally, calling the EMIX Option, whether Power or Load, defines a strike price, which is expressed either as an absolute amount or as a price relative to the current market.

The EMIX Resource describes a service that could be brought to market. Each Resource may have a lag time before responding. Non-trivial responses may take a while during which the amount of power is ramping up or down. In the IEC TC57 [CIM], these ramp rates are expressed as a Ramp Rate Curve, as shown in Figure 4‑5.

Description: Description: 9fdbc019-6518-4c33-abac-b5dc4b336218

Figure 4‑5: Ramp Rate Curve—CIM Style

Resources may also have minimum responses, or maximum run times, or minimum required times between each invocation.

By expressing resources in terms of capabilities and ramp rates, a potential purchaser can determine if a resource meets his or her needs, tendering a single resource to a variety of purchase scenarios.

Many message payloads in Energy Interoperation consist of the delivery of EMIX objects. The reader who is not familiar with EMIX and its capabilities may have a hard time understanding what message each of the services delivers.

The simplest EMIX object, the product describing gluon and the sequence of a single interval containing a single price collapse down to product, time, duration, and price.

4.3 Using Gluons to Define Contracts

Figure 4‑6: Schematic of Use of EMIX and WS-Calendar to describe Power Contract

  1. Power source defines product to market (Sequence and Gluon 1).
  2. Product is offered to market on a particular day ([1] and Gluon 2) (Date but not time, required price specified)
  3. Transaction specifies start time (9:00) and duration (6:30) (Gluon 3), inherited by Sequence through Gluons 2 and 1. Interval B (linked to Gluon 1) is the interval that starts at 9:00.

4.4 Applying EMIX and WS-Calendar to a Power Event

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

Figure 4‑7: A Demand Response Market Schematic

Note first that there are two schedules of prices. The Building Price of energy 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 its own EMIX description.

The dispatch level, i.e., the contracted 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 contracted 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. These are fixed durations are communicated from the VEN to the VTN, which then must respect them in contracts it awards the VEN. These durations are expressed in the EMIX Resource Description provided by the VEN, and reflected in the Power Contract awarded by the VTN.

4.5 Introduction to Services

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.

We use this terminology through all service definitions in this standard.

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.

5      Security and Composition [Non-Normative]

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.[6]

5.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 5‑1: Web of Example DR Interactions

We specifically model a Reliability DR Event initiated by the Independent System Operator[7] 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 contract commitments to A will arrange its business and interactions to meet B’s business needs.

       G receives the signal from aggregator B. In the contract between G and B, there are service, response, and likely security and other requirements. To meet its contractual 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 5—1: Interactions and Actors for Security and Reliability Example


Structure Role

Possible Actor Names



System Operator


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



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

Regional Office


VEN (wrt G and wrt E)



VEN (wrt  A, VTN wrt L)

Local Utility


5.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.

5.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 contracts, 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,


6      Energy Interoperation Services

In the following sections, we define Energy Interoperation services and operations. All communication between customer devices and energy service providers is through the ESI.

For transactive services, the customer will receive tenders (priced offers) of service and possibly make tenders (priced offers) of service.

If the customer is a participant in a demand response program, each ESI is the interface to a dispatchable resource (Resource), that is, to a single logical entity. A Resource may or may not expose any subordinate Assets.

Under a demand response program, an Asset is an end device that is capable of shedding load in response to Demand Response Events, Electricity Price Signals or other system events (e.g. under frequency detection). Assets are under the control of a Resource, and the resource has chosen to expose it to the VTN. The VTN can query the State of an Asset, and can call on an asset for a response. The Resource (VEN) mediates all Asset interactions, as per its agreement with the resource manager or VTN. Assets, by definition, are only capable of consuming Direct Load Control and Pricing messages, and then only as mediated by the Resource.

If an Asset, in turn, has its own Assets, it does not reveal them through the VEN. The Asset has no direct interactions with the VTN.

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

We divide the services into three broad categories:

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, load and usage projection, and Demand Response (with the functionality of [OpenADR]).

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

7      Transactive Services

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

For transactive services, the roles are Parties and Counterparties; as, if, and when an option contract or a Resource (Demand Response) contract is concluded, the Parties adopt a VTN or VEN role for subsequent interactions. The terminology of this section is that of business agreements: tenders, quotes, and contract execution and (possibly delayed) performance under called contract.

The negotiations, quotes, tenders, and acceptances that may lead to a contract also serve to define the VTN and VEN roles. Register Services

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 contract which will determine the VTN and VEN roles of the respective parties.

Registration information will be drawn from IRC and UCA and OpenADR requirements.

Table 7—1: Register Services




Service Consumer

Service Provider





















7.1.1 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.

Description: Eiparty.jpg

Figure 7‑1: EiParty UML Class Diagram

7.1.2 Operation Payloads for the EiRegisterParty Service

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

Description: EiRegisterParty Payloads.jpg

Figure 7‑2: UML Class Diagram for EiRegisterParty Service Operation Payloads

7.2 Pre-Contract Services

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

Price distribution in the sense of price signals in [OpenADR] would use 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 contracts are [EMIX] artifacts, which contain terms such as schedules and prices in varying degrees of specificity or concreteness.

Table 7—2: Pre-Contract Tender Services




Service Consumer

Service Provider

































Table 7—3: Pre-Contract Quote Services




Service Consumer

Service Provider







And sends the quote












Request a quote or indication of interest (pull)






For broadcast or distribution of price (push)


7.2.1 Information Model for the EiTender and EiQuote Service

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.

7.2.2 Operation Payloads for the EiTender Service

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

Description: EiOffer Payloads.jpg

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


7.2.3 Operation Payloads for the EiQuote Service

Description: EiQuote Payloads.jpg

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

7.3 Contract Management Services

The service operations in this section manage the exchange of contracts. 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.

Table 7—4: Contract Management Services




Service Consumer

Service Provider







And send Contract




















7.3.1 Information Model for the EiContract Service

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

7.3.2 Operation Payloads for the EiContract Service

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

Description: EiContract Payloads.jpg

Figure 7‑5: UML Class Diagram of EiContract Service Operation Payloads

7.4 Post-Contract 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 contracts (or 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 contracts create much of the variance in today’s DR markets.

As the Full Requirements Verification necessarily incorporates the Energy Usage Information exchange, this section first addresses EUI.

These sections will apply the results of the SGIP Priority Action Plan 10 standard (when ratified) along with [WS-Calendar], and are all TBD pending ratification of [NAESB EUI]. The NAESB Measurement and Verification Business Practice will also be considered.

7.4.1 Energy Usage Information

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

Table 7—5: Energy Usage Information




Service Consumer

Service Provider



















Cancel measurement request





Either Information Model for the EiUsage Service Operation Payloads for the EiUsage Service

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

7.4.2 Full Requirements Verification

Full requirements verification involves a combination of usage and load measurement and information exchange; contracts often include demand charges (also called demand ratchets) that affect cost. TBD pending ratification of [NAESB EUI] Information Model for the Full Requirements Verification Service Operation Payloads for the Full Requirements Verification Service

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

8      Event Services

8.1 EiEvent Service

The Event Service is used to call for performance under a contract. 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 Contract. 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 Contract.

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

Table 8—1: Event Services



Response Operation

Service Consumer

Service Provider







Create invokes a new event



















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 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 the figure below.

An event has certain information including


Figure 8‑1: UML Class Diagram for the EiEvent and Associated Classes

8.1.2 Operation Payloads for the EiEvent Service

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

Description: EiEvent Payloads-wd14

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

8.2 Feedback Service

Feedback communicates provides information about the state of the Asset or Resource as it responds to a DR Event signal. This is distinct from Status, which communicates information about the state of the Event itself. See section 9.3Status 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.

Table 8—2: Feedback Service




Service Consumer

Service Provider




















8.2.1 Information Model for the EiFeedback Service

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

Description: EiFeedback.jpg

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

8.2.2 Operation Payloads for the EiFeedback Service

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

Description: EiEvent Payloads.jpg

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

8.3 EiProgram Service

The EiProgram service distributes Program Calls, which are simple levels for requested action. The levels are purely nominal, and are structured so that any program with N levels of requested response can be represented easily and mapped to and from.

This is analogous to the EiQuote service, used for communicating full [EMIX] price and product definition quotes.

Programs for demand response vary considerably. One area of variation is in how many levels of requested response are defined, and what they are called. The EiProgram services maps any number of nominal levels to a simple numeric model, allowing the same equipment to function in programs with any number of levels, and with optional application level mapping (outside the scope of this standard) for display or other purposes.

Some examples of programs and levels are

·         OpenADR—Four levels, Low, Moderate, High, Special [emergency]

·         Smart Energy Profile 2—Three levels, Low, Moderate, High

·         EPA Energy Star 2.0 Interfaces—Four levels, Green, Amber, Orange, Red

EiRequestProgram and EiSentProgram respectively request and send Program Metadata, which in this version of this standard includes the number of levels (responseUpperLimit, with the lower limit always being the integer one) and the so-called normal level (responseNormalValue, which must be in 1 to the responseUpperLimit inclusive). Not all programs will assume an ordering, and instead may use purely nominal levels, in which case responseNormalValue will be of limited use.

Program Calls [“ProgCalls”] are communicated from a VTN to a VEN or by broadcast.[8]

Table 8—3: EiProgram Service




Service Consumer

Service Provider







Gets selected Program metadata






And sends the Call












Request outstanding Calls (pull)






For broadcast or distribution of Calls (push)


8.3.1 Information Model for the EiProgram Service

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

Description: EiProgram.jpg

Figure 8‑5: UML Class Diagram for the EiProgram Class

8.3.2 Operation Payloads for the EiProgram Service

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

Description: EiProgam Payloads.jpg

Figure 8‑6: UML Class Diagram for EiProgram Service Operation Payloads


9      Support Services

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].

Constraints and OptOut are similar in that they communicate when an event will not be acted upon. Constraints are long-term restrictions on response and are often at registration or Contract negotiation; OptOut is a short-term restriction on likely response.

The combination of Constraints and OptOut state together (a logical or) defines the committed response from the VEN.

Constraints and OptOut apply to curtailment and DER interactions, and only indirectly to price distribution interactions.

9.1 EiConstraint Service

Constraints are set by the VEN and indicate when an event may or may not be accepted and executed by that VEN. The constraints (and OptOut schedules) for its VENs help the VTN estimate response to an event or request.

Constraints are a long-term availability description and may be complex. The next section describes OptOut and how opting out affects predicted behavior.

When constraints are set, opting in or out does not affect the constraints—opting out is temporary unavailability, which may have contract consequences if an event is created during the optout period.

The modeling for constraints includes attributes such as blackout intervals, valid intervals, and behavior indications for the situation where an EiEvent overlaps a constrained time interval.

Table 9—1: Constraint Service




Service Consumer

Service Provider

























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

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

·         ACCEPT – accept the issued EiEvent regardless of conflicts with the EiConstraint

·         REJECT – reject any EiEvent whose schedule conflicts with the EiConstraint

·         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 EiConstraint

9.1.1 Information Model for the Constraint Service

Description: EiConstraint.jpg

Figure 9‑1: UML Class Diagram for the EiConstraint and Associated Classes

9.1.2 Operation Payloads for the EiConstraint Service

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

Description: EiConstraint Payloads.jpg

Figure 9‑2: UML Class Diagram for EiConstraint Service Operation Payloads

9.2 Opt Out Service

The Opt Out service creates and communicates Opt Out schedules from the VEN to the VTN. Optout schedules are combined with EiConstraints to give a complete picture of the willingness of the VEN to respond to EiEvents that may be created by the VTN.

Table 9—2: Opt-Out Service




Service Consumer

Service Provider


























9.2.1 Information Model for the Opt Out Service

Opt Out is a temporary siutation indicating that the VEN will not respond to a particular event or in a specific time period, without changing the potentially complex Program Constraints. The EiOptout schedule is an [EMIX] businessSchedule. In comparison the EiConstraint class uses two such businessSchedules, one to indicate when a scheduled EiEvent is acceptable and another to indicate when a scheduled EiEvent is not acceptable.

The EiOptout model is in a sense only one half of the constraint model—the businessSchedule describes when a scheduled EiEvent is not acceptable to the VEN.


Description: EiOptout.jpg

Figure 9‑3: UML Class Diagram for the EiOptout Class

9.2.2 Operation Payloads for the Opt Out Service

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

Description: EiOptout Payloads.jpg

Figure 9‑4: UML Class Diagram for EiOptout 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 Assets or 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. The operation EiRequestStatus requests status for each EiAsset associated with a given VEN.

Table 9—3: Status Services




Service Consumer

Service Provider







Status of Assets associated with a VEN


9.3.1 Information Model for the Status Service


Description: EiStatus.jpg

Figure 9‑5: UML Class Diagram for the EiStatus Class

9.3.2 Operation Payloads for the Status Service

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

Description: EiStatus Payloads.jpg

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

10 Conformance

Up until this draft, the core services and payloads have been changing too often for the committee to focus closely on conformance issues. For Interoperability on the scale of the grid, the conformance requirements require the inputs from a wide range of perspectives and approaches. The Technical Committee especially welcomes suggestions and requirements for conformance.

The SGIP SGTCC has just released v1.0 of their Interoperability Process Reference Manual:

In section 2 they state,

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

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

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

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

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

This specification cannot provide complete conformance requirements for all implementations. Implementations built upon Energy Interoperation will need to develop their own conformance profiles. For example, different implementations will support a different mix of business-to-business and business-to-consumer, with quite different privacy requirements. Each will require its own security, message requirements (what part of EI to implement), and what other standards are included.

Conformance testing requires that any product that claims to implement EI (as detailed in its PICS statement, which might indicate a limited set of services), can in fact implement these services according to the standard, correctly forming each supported service request, and consuming responses, producing responses as needed, with acceptable parameters, and failing in appropriate and defined ways when presented with bad data.

The Technical Committee welcomes comments that point to testing and conformance standard or that discuss the roles of those standards in an interoperability testing process. The Technical Committee also welcomes suggestions for the organization that should be the Interoperability Testing and Certification Authority for Energy Interoperation.

A.  Background and Development history

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 assets, and their problems, are generally named distributed energy resources (DER). The NIST Smart Grid Interoperability Roadmap sees 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 pricing, 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[10]. 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 pricing, reliability, and emergency signals to meet business and energy needs, and scale, using a variety of communication technologies.

B.  Collaborative Energy

Collaborative energy relies on light coupling of systems with response urgency dictated by economic signals. Customers are able to respond as little or as aggressively as they want. “Every brown-out is a pricing failure.”

Because collaborative energy requires no detailed knowledge of the internal systems of the end nodes, it is indifferent to stresses caused by changes in technology within the end node, and is more accepting of rapid innovation

Because collaborative energy offers economic rewards without loss of autonomy, end nodes may seek to maximize their economic opportunities. Collaborative energy creates a market for end-node based technologies to save, store, or generate electricity on demand.

Collaborative energy signals are results oriented signals and are agnostic about technology. Light, loose integrations based on service–oriented signals adopt enterprise best practices.

B.1 Collaborative Energy in Residences

It is a long-held dictum that residences were unable to participate effectively in price-based demand response. The groundbreaking Olympic Peninsula Project disproved that assumption, as homeowners were able to better reduce energy usage and respond to local congestion when responding to price signals than were homes under managed energy.

The Olympic Peninsula Project was distinguished from a traditional managed energy project by its smart thermostat and meter. Direct control of building systems using managed energy approaches were transferred from the managing utility to the thermostat. Price signals and an innovative user interface then transferred autonomy and decision-making to the homeowner.

B.2 Collaborative Energy in Commercial Buildings

Larger commercial buildings have long had the intelligent infrastructure necessary for collaborative energy. Large buildings have custom control systems, often based on PCs. These custom control systems make commercial ideal candidates for collaborative energy.

The growth of collaborative energy in commercial buildings will be stimulated the sharing of live usage and price information.

B.3 Collaborative Energy in Industry

It is often expensive for an industrial site to curtail significant load on short notice. Industrial processes are characterized by long run times and large, if predictable, energy use. Industrial sites are not a primary focus of DR.

Industrial sites do have three means of participating in collaborative energy. (1) They can schedule those long running processes in advance. (2) Because of their scale, industrial sites can manage the shape of their load, balancing internal processes. (3) Industrial sites are often supported by combined heat and power plants that can be assets to a stressed grid.

Collaborative energy scheduling in industrial sites requires that the plant operators know the energy profile of long-running processes. The site operators can then request bids that energy profile on various schedules. Using price signals, the supplier can influence when those processes occur. This allows large-scale load shifting and improves the suppliers’ ability to estimate loads.

Within a large facility, there may be many motors, and many different environmental systems. Such loads are episodic, using lot so energy when running, and none when they are not. Large energy customers are often charged for peak load, as well as for overall energy use. Operators can coordinate systems so that energy spikes from different systems do not coincide.

This sort of load shaping becomes more important as the operating safety margins of the grid become less. While load shaping may cause some inconvenience at any time, it is much more valuable to supplier during peak energy events on the grid. Differential pricing by time or dynamic pricing for load spikes as well as overall load size can aid in grid stability. Time differential pricing of usage spikes can also encourage shifting of overall load, as the convenience of daytime operations is offset by the convenience ignoring load shaping.

Generation that produces multiple usable energy streams is known as cogeneration. Combined heat and power, wherein a facility produces electricity and steam is the most common kind of cogeneration. A cogeneration facility can often, within limits, vary the output of thermal and electrical energy. Because it usually has a distribution system for thermal energy, it has the means to store thermal mass. Economic incentives through collaborative energy give industrial sites the incentives to further develop these capabilities.

B.4 Summary of Collaborative Energy

Collaborative energy relies on intelligence in each end node of the grid. That intelligence is embedded in systems that understand the particular features of each end node better than a central supplier ever will. In particular, systems in the end node will better understand the business processes and aspirations of the occupants of that end node than will the grid.

Collaborative energy response by each end node will be more variable than is managed energy. An end node may decide whether to participate in any event. The end node may also choose to participate more fully, as an autonomic decision, in a particular DR event.

If price and risk arbitrage, coupled with obscure regulated accounting, are barriers to the smart grid, the generative solution includes shared honest, transparent accounting and limiting the interoperation points and complexity for the smart grid. In other words, we need to treat energy markets more as we treat financial markets.

Under collaborative energy, service performance matters more than process performance. This reduces the complexity required at the grid level to manage distributed energy resources (DER). Both generation and drain-down of storage may be indistinguishable from demand response. Battery filling is just one more service responding the cheap energy.

C.  Glossary

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. See Contract.

Asset: An end device that is capable of shedding load in response to Demand Response Events, Electricity Price Signals or other system events (e.g. Under-Frequency Detection). Assets are under the control of a Resource. A VTN can query an Asset for its state, and call on an Asset for a response. The Resource mediates all Asset interactions, as per its agreement with the VTN. Assets are limited to consuming Direct Load Control and Pricing messages. If an Asset has its own Assets, it does not reveal them to the VEN.

Contracts are individual transactions entered into under an Agreement.

DR Asset: see Asset

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 an Asset or Resource in relation to an Event

Resource (as used in Energy Interoperation): a Resource is a logical entity is dispatchable. A Resource may or may not expose any subordinate Assets. In any case, the Resource is solely responsible for its own response, and those of its subordinate Assets.

Resource (as used 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 an Asset or 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.

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

D.  Acknowledgements

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


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 -


NAESB Smart Grid Standards Development Subcommittee Co-chairs:

Brent Hodges, Reliant

Robert Burke, ISO New England

Wayne Longcore, Consumers Energy

Joe Zhou, Xtensible Solutions

E.  Revision History





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


Toby Considine

Reduced core functions to two service groups, transactional energy and eliminated references to managed energy

1.0 WD 09


Toby Considine


1.0 WD 10


William Cox

Updated interaction model per analysis and drawings in TC meetings in April and early May

1.0 WD 11


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


William Cox

Editorial and content corrections and updates. Consistency of tone; flagged portions that are more closely related to EMIX.

1.0 WD 13


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


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


William Cox
Toby Considine

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

1.0 WD 16


William Cox

Added missing Section 6

1.0 WD 17


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


Toby Considine

Responded to formal comments
Added additional language on WS-Calendar
Incorporated missing ProgramCall
Added Simple Market Model to Interactions


[1] We are indebted for the Virtual End Node term to EPRI,

[2] Using North American Terminology.

[3] The case of a VTN with zero VENs may be theoretically interesting but has little practical value, hence in a later section we formally describe the VENs having cardinality 1..n.

[4] The model allows e.g. Demand Resources to participate in more than one interaction, that is, in more than one Demand Response program or offer or with more than one aggregator.

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

[6] See e.g. the STUXNET worm effects on a monoculture of software SCADA systems, 2010. See

[7] Using North American Terminology.

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

[9] This will require further definition in a future draft when Program metadata is defined.

[10] Cogeneration refers the combined generation of multiple energy resources, i.e., a boiler that both spins a turbine to generate electricity and produces team to run an industrial process. Cogeneration can include any number of energy distributions, including heat, cold, pressure, et al.