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, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.
[RFC2246] T.
Dierks, C. Allen Transport Layer Security (TLS) Protocol Version 1.0, http://www.ietf.org/rfc/rfc2246.txt,
IETF RFC 2246, January 1999.
[SOA-RM] OASIS Standard, Reference Model for Service Oriented Architecture
1.0, October 2006. http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf
[EMIX] OASIS Committee Specification Draft 01, Energy
Market Information Exchange 1.0, November 2010. http://docs.oasis-open.org/emix/emix/v1.0/csd01/emix-v1.0-csd01.pdf
[WS-Calendar] OASIS
Committee Specification Draft, WS-Calendar 1.0, September 2010. http://docs.oasis-open.org/ws-calendar/ws-calendar/v1.0/CD01/ws-calendar-1.0-spec-cd-01.pdf
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. http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/os/ebms_core-3.0-spec-os.pdf
[EISA2007] Energy
Independence and Security Act of 2007, http://nist.gov/smartgrid/upload/EISA-Energy-bill-110-140-TITLE-XIII.pdf
[Framework] National
Institute of Standards and Technology, NIST Framework and Roadmap for Smart
Grid Interoperability Standards, Release 1.0, January 2010, http://nist.gov/public_affairs/releases/upload/smartgrid_interoperability_final.pdf
[Galvin] Galvin
Electricity Initiative, Perfect Power, http://www.galvinpower.org/perfect-power/what-is-perfect-power
[ID-CLOUD] OASIS
Identity in the Cloud Technical Committee
http://www.oasis-open.org/committees/id-cloud
[KMIP] OASIS
Standard, Key Management Interoperability Protocol Specification Version 1.0,
October 2010
http://docs.oasis-open.org/kmip/spec/v1.0/kmip-spec-1.0.pdf
[SAML] OASIS Standard,
Security Assertion Markup Language 2.0, March 2005. http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
[OASIS SCA] OASIS Service
Component Architecture Member Section
http://www.oasis-opencsa.org/sca
[OASIS PMRM] OASIS Privacy
Management Reference Model (PMRM) Technical Committee, http://www.oasis-open.org/committees/pmrm
[SPML] OASIS
Standard, Service Provisioning Markup Language (SPML) v2 - DSML v2 Profile,
April 2006. http://www.oasis-open.org/committees/download.php/17708/pstc-spml-2.0-os.zip
[SOA-RA] OASIS
Public Review Draft 01, Reference Architecture for Service Oriented
Architecture Version 1.0, April 2008
http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/soa-ra-pr-01.pdf
[TEMIX] OASIS Working
Draft, Transactional Energy White Paper, May 2010. http://www.oasis-open.org/committees/download.php/37954/TeMIX-20100523.pdf
[WS-Addr] Web
Services Addressing (WS-Addressing) 1.0, W3C Recommendation, http://www.w3.org/2005/08/addressing.
[WSFED] OASIS Standard,
Web Services Federation Language (WS-Federation) Version 1.2, 01 May
2009 http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.doc
[WSRM] OASIS Standard, WS-Reliable Messaging 1.1,
November 2004.
http://docs.oasis-open.org/wsrm/ws-reliability/v1.1/wsrm-ws_reliability-1.1-spec-os.pdf
[WS-SecureConversation] OASIS Standard,
WS-SecureConversation 1.3, March 2007. http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/ws-secureconversation-1.3-os.pdf
[WS-Security] OASIS Standard,
WS-Security 2004 1.1, February 2006.
http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf
[WS-SX] OASIS Web
Services Secure Exchange (WS-SX) Technical Committee
http://www.oasis-open.org/committees/ws-sx
[XACML] OASIS
Standard, eXtensible Access Control Markup Language 2.0, February 2005. http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf
1.4 Contributions
The NIST Roadmap for Smart Grid Interoperability Standards
described in the [Framework] requested that many standards development
organizations (SDOs) and trade associations work together closely in
unprecedented ways. An extraordinary number of groups came together and
contributed effort, and time, requirements, and documents. Each of these groups
further gathered together, repeatedly, to review the work products of this
committee and submit detailed comments. These groups contributed large numbers
of documents to the Technical Committee. These efforts intersected with this
specification in ways almost impossible to unravel, and the committee
acknowledges the invaluable works below which are essential to understanding
the North American Grid and its operation today, as well as its potential
futures.
NAESB Smart Grid Standards Development Subcommittee:
The following documents are password
protected. For information about obtaining access to these documents, please
visit www.naesb.org or contact the NAESB
office at (713) 356 0060.
[NAESB EUI] NAESB REQ Energy Usage Information Model: http://www.naesb.org/member_login_check.asp?doc=req_rat102910_req_2010_ap_9d_rec.doc
[NAESB EUI] NAESB WEQ Energy Usage Information Model: http://www.naesb.org/member_login_check.asp?doc=weq_rat102910_weq_2010_ap_6d_rec.doc
The following documents are under development and subject to
change.
[NAESB PAP 09] Phase Two Requirements Specification for
Wholesale Standard DR Signals – for NIST PAP09: http://www.naesb.org/pdf4/weq_2010_ap_6c_rec_101510_clean.doc
[NAESB PAP 09] Phase Two Requirements Specification for Retail
Standard DR Signals – for NIST PAP09: http://www.naesb.org/pdf4/retail_2010_ap_9c_rec_101510.doc
The ISO / RTO Council Smart Grid Standards Project:
Information Model – HTML: http://www.isorto.org/atf/cf/%7B5B4E85C6-7EAC-40A0-8DC3-003829518EBD%7D/IRC-DR-InformationModel-HTML-Condensed_Rev1_20101014.zip
Information Model – EAP: http://www.isorto.org/atf/cf/%7B5B4E85C6-7EAC-40A0-8DC3-003829518EBD%7D/IRC-DR-InformationModel-EAP-Condensed_Rev1_20101014.zip
XML Schemas: http://www.isorto.org/atf/cf/%7B5B4E85C6-7EAC-40A0-8DC3-003829518EBD%7D/IRC-DR-XML_Schemas_Rev1_20101014.zip
Eclipse CIMTool Project: http://www.isorto.org/atf/cf/%7B5B4E85C6-7EAC-40A0-8DC3-003829518EBD%7D/IRC-DR-CIMTool-Project-Workspace_Rev1_20101014.zip
Interactions - Enrollment and Qualification: http://www.isorto.org/atf/cf/%7B5B4E85C6-7EAC-40A0-8DC3-003829518EBD%7D/IRC-DR-Interactions-HTML_Enrollment_And_Qualification_Rev1_20101014.zip
Interactions - Scheduling and Award Notification: http://www.isorto.org/atf/cf/%7B5B4E85C6-7EAC-40A0-8DC3-003829518EBD%7D/IRC-DR-Interactions-HTML_Scheduling_And_Award_Notification_Rev1_20101014.zip
Interactions - Deployment and Real Time Notifications: http://www.isorto.org/atf/cf/%7B5B4E85C6-7EAC-40A0-8DC3-003829518EBD%7D/IRC-DR-Interactions-HTML_Deployment_And_RealTime_Communications_Rev1_20101014.zip
Interactions - Measurement and Performance: http://www.isorto.org/atf/cf/%7B5B4E85C6-7EAC-40A0-8DC3-003829518EBD%7D/IRC-DR-Interactions-HTML_Measurement_And_Performance_Rev1_20101014.zip
Interactions Non-Functional Requirements: http://www.isorto.org/atf/cf/%7B5B4E85C6-7EAC-40A0-8DC3-003829518EBD%7D/IRC-DR-Non-Functional_Requirements_Rev1_20100930.pdf
UCAIug OpenSG OpenADR Task Force:
Need definitive and permanent links here
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
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.
- 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.
- 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.
- It is likely that most end users, with some exceptions
among Commercial and Industrial (C&I) customers, will not interact
directly with wholesale market.
- 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.
- 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.
- 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.
- 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
- 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.
Interaction patterns and service definitions to support the
following are in scope for Energy Interoperation:
- Market communications to support transactive energy. (see [TEMIX])
- Specific offerings by end nodes to alter energy use.
- Measurement and confirmation of actions taken, including
but not limited to curtailment, generation, and storage, including load
and usage information, historical, present, and projected.
- Notifications requesting performance on contracts offered
or executed
- Information models for contracts and product communication
- Service definitions for Energy Interoperation
The following are out of scope for Energy Interoperation:
- Requirements specifying the type of contract, agreement,
or tariff used by a particular market.
- Validation and verification of contract performance,
except for validation of curtailment and generation.
- Communication (e.g. transport method) other than Web services
to carry the messages from one point to another. The messages specified in
Energy Interoperation can be transmitted via a variety of transports.
2.3 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.
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.
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.
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.
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.
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.
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)]..
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
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
|
Label
|
Structure Role
|
Possible Actor Names
|
|
A
|
VTN
|
System Operator, DR Event Initiator, Microgrid controller,
landlord
|
|
B
|
VEN (wrt A),
VTN (wrt F, G, H)
|
Aggregator, microgrid element, tenant, floor, building,
factory
|
|
G
|
VEN (wrt B),
VTN (wrt I, J, L)
|
Microgrid controller, building, floor, office suite,
process controller, machine
|
|
L
|
VEN (wrt G and wrt E)
|
Microgrid element, floor, HVAC unit, machine
|
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.
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.
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.
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.
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
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.
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.
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.
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.
Figure 4‑6: Schematic of Use of EMIX and WS-Calendar to describe Power Contract
- Power source defines product to market (Sequence and Gluon
1).
- Product is offered to market on a particular day ([1]
and Gluon 2) (Date but not time, required price specified)
- 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.
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.
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.
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
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
|
Label
|
Structure Role
|
Possible Actor Names
|
|
A
|
VTN
|
System Operator
|
|
B
|
VEN (wrt A),
VTN (wrt F, G, H)
|
Aggregator
|
|
G
|
VEN (wrt B),
VTN (wrt I, J, L)
|
Regional Office
|
|
L
|
VEN (wrt G and wrt E)
|
Store
|
|
E
|
VEN (wrt A, VTN wrt L)
|
Local Utility
|
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.
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,
(SEE http://www.oasis-open.org/committees/tc_cat.php?cat=security)
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:
- Transactive Services—for implementing energy transactions,
registration, and tenders
- Event Services—for implementing events and feedback
- Support Services—for additional capabilities
The structure of each section is a table with the service
name, operations, service provider and consumer, and notes in columns.
The services are grouped so that profiles can be defined for
purposes such as price distribution, 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.
Transactive Services define and support the lifecycle of
transactions inside an overarching agreement, from initial quotations and
indications of interest to final settlement. The phases are
- Registration—to enable further phases
- Pre-Contract—preparation for contract with a contract the
result of an accepted offer
- Contract Services—managing executed contracts
- Post-Contract—settlement, energy used or demanded,
payment, position
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
|
Operation
|
Response
|
Service Consumer
|
Service Provider
|
Notes
|
|
EiRegister
|
EiRegisterParty
|
EiRegisteredParty
|
Party
|
Party
|
|
|
EiRegister
|
EiRequestRegistration
|
EiSendRegistration
|
Party
|
Party
|
|
|
EiRegister
|
EiCancelRegistration
|
EiCanceledRegistration
|
Party
|
Party
|
|
The details of a Party are outside the scope of this
specification. The application implementation needs to identify additional
information beyond that in the class EiParty.
Figure 7‑1: EiParty UML Class Diagram
The [UML] class
diagram describes the payloads for the EiFeedback service operations.
Figure 7‑2: UML Class Diagram for EiRegisterParty Service Operation Payloads
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
|
Operation
|
Response
|
Service Consumer
|
Service Provider
|
Notes
|
|
EiTender
|
EiCreateTender
|
EiCreatedTender
|
Party
|
Party
|
|
|
EiTender
|
EiRequestTender
|
EiSentTender
|
Party
|
Party
|
|
|
EiTender
|
EiAcceptTender
|
EiAcceptedTender
|
Party
|
Party
|
|
|
EiTender
|
EiSendTender
|
EiReceivedTender
|
Party
|
Party
|
|
|
EiTender
|
EiCancelTender
|
EiCanceledTender
|
Party
|
Party
|
|
Table
7—3: Pre-Contract Quote Services
|
Service
|
Operation
|
Response
|
Service Consumer
|
Service Provider
|
Notes
|
|
EiQuote
|
EiCreateQuote
|
EiCreatedQuote
|
Party
|
Party
|
And sends the quote
|
|
EiQuote
|
EiCancelQuote
|
EiCanceledQuote
|
Party
|
Party
|
|
|
EiQuote
|
EiRequestQuote
|
EiSentQuote
|
Party
|
Party
|
Request a quote or indication of interest (pull)
|
|
EiQuote
|
EiDistributeQuote
|
--
|
Party
|
Party
|
For broadcast or distribution of price (push)
|
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.
The [UML] class
diagram describes the payloads for the EiTender and EiQuote service operations.
Figure 7‑3: UML Class Diagram for the Operation Payloads for the EiTender Service
Figure 7‑4: UML Class Diagram for the EiQuote Service Operation Payloads
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
|
Operation
|
Response
|
Service Consumer
|
Service Provider
|
Notes
|
|
EiContract
|
EiCreateContract
|
EiCreatedContract
|
Party
|
Party
|
And send Contract
|
|
EiContract
|
EiChangeContract
|
EiChangedContract
|
Party
|
Party
|
|
|
EiContract
|
EiCancelContract
|
EiCanceledContract
|
Party
|
Party
|
|
|
EiContract
|
EiRequestContract
|
EiSentContract
|
Party
|
Party
|
|
Contracts are [EMIX] artifacts with the
identification of the Parties.
The [UML] class
diagram describes the payloads for the EiContract service operations.
Figure 7‑5: UML Class Diagram of EiContract Service Operation Payloads
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.
These operations create, change, and allow exchange of
Energy Usage Information. TBD pending ratification of [NAESB EUI]
Table 7—5: Energy Usage Information
|
Service
|
Operation
|
Response
|
Service Consumer
|
Service Provider
|
Notes
|
|
EiUsage
|
EiCreateUsage
|
EiCreatedUsage
|
Either
|
Either
|
|
|
EiUsage
|
EiChangeUsage
|
EiChangedUsage
|
Either
|
Either
|
|
|
EiUsage
|
EiCancelUsage
|
EiCanceledUsage
|
Either
|
Either
|
Cancel measurement request
|
|
EiUsage
|
EiRequestUsage
|
EiSentUsage
|
Either
|
Either
|
|
7.4.1.1 Information Model for the EiUsage Service
7.4.1.2 Operation Payloads for the EiUsage Service
The [UML] class diagram describes the payloads for the
EiUsage service operations.
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]
7.4.2.1 Information Model for the Full Requirements Verification Service
7.4.2.2 Operation Payloads for the Full Requirements Verification Service
The [UML] class diagram describes the payloads for
the EiFullRequirementsVerification service operations.
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
|
Service
|
Operation
|
Response Operation
|
Service Consumer
|
Service Provider
|
Notes
|
|
EiEvent
|
EiCreateEvent
|
EiCreatedEvent
|
VTN
|
VEN
|
Create invokes a new event
|
|
EiEvent
|
EiChangeEvent
|
EiChangedEvent
|
VTN
|
VEN
|
|
|
EiEvent
|
EiCancelEvent
|
EiCanceledEvent
|
VTN
|
VEN
|
|
|
EiEvent
|
EiRequestEvent
|
EiSentEvent
|
Either
|
Either
|
|
Since the event is the core Demand Response information
structure, we begin with Unified Modeling Language [UML] diagrams for
the EiEvent class and for each of the operation payloads.
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
- A schedule (and a reference to the schedule)—attributes schedule
and scheduleGluonRef.(Note: a Schedule includes 1 or more
intervals, each of which could have a different program level, price, or
whatever other information is being communicated by this Event.)
- An identifier for the event—eventID
- The program or agreement under which the event was issued—program
- A modification counter, a timestamp for the most recent
modification, and a reason—modificationNumber, modificationDateTime,
and modificationReason
- A location to which the event applies—location—which
may be a geospatial location [OGC], an address [UBL], or grid electrical
coordinates.
- Baseline value and a timestamp for that value, used to
compare curtailment and “normal” usage—energyBaselineValue and energyBaselineTimestamp
- Information on status, comments, and other information—notificationAcknowledgement,
operatingDay, performanceComment, reportingInterval, responseValue,
status, and vtnComment
Figure 8‑1: UML Class Diagram for the EiEvent and Associated Classes
The [UML] class
diagram describes the payloads for the EiEvent service operations.
Figure 8‑2: UML Class Diagram for EiEvent Service Operation Payloads
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.3 “Status Service” for a discussion of Status.
EiFeedback operations are independent of EiEvent operations
in that they can be requested at any time independent of the status or history
of EiEvents.
Table 8—2: Feedback Service
|
Service
|
Operation
|
Response
|
Service Consumer
|
Service Provider
|
Notes
|
|
EiFeedback
|
EiCreateFeedback
|
EiCreatedFeedback
|
VTN
|
VEN
|
|
|
EiFeedback
|
EiCancelFeedback
|
EiCanceledFeedback
|
VTN
|
VEN
|
|
|
EiFeedback
|
EiRequestResponseSched
|
EiSentResponseSched
|
VTN
|
VEN
|
|
EiFeedback is requested by the VTN and supplied by the
VEN(s).
Figure 8‑3: UML Class Diagram for the EiFeedback Class
The [UML] class
diagram describes the payloads for the EiFeedback service operations.
Figure 8‑4: UML Class Diagram for EiFeedback Service Operation Payloads
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.
Table 8—3: EiProgram Service
|
Service
|
Operation
|
Response
|
Service Consumer
|
Service Provider
|
Notes
|
|
EiProgram
|
EiRequestProgram
|
EiSentProgram
|
VEN
|
VTN
|
Gets selected Program metadata
|
|
EiProgram
|
EiCreateProgCall
|
EiCreatedProgCall
|
Party
|
Party
|
And sends the Call
|
|
EiProgram
|
EiCancelProgCall
|
EiCanceledProgCall
|
Party
|
Party
|
|
|
EiProgram
|
EiRequestProgCall
|
EiSentProgCall
|
Party
|
Party
|
Request outstanding Calls (pull)
|
|
EiProgram
|
EiDistributeProgCall
|
--
|
Party
|
Party
|
For broadcast or distribution of Calls (push)
|
The key class is EiProgram,
which has associations with the classes Location, EventInfo, Sequence (from
[WS-Calendar], and Program. See the figure below.
Figure 8‑5: UML Class Diagram for the EiProgram Class
The [UML] class
diagram describes the payloads for the EiProgram service operations.
Figure 8‑6: UML Class Diagram for EiProgram Service Operation Payloads
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.
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
|
Operation
|
Response
|
Service Consumer
|
Service Provider
|
Notes
|
|
EiConstraint
|
EiCreateConstraint
|
EiCreatedConstraint
|
VEN
|
VTN
|
|
|
EiConstraint
|
EiChangeConstraint
|
EiChangedConstraint
|
VEN
|
VTN
|
|
|
EiConstraint
|
EiDeleteConstraint
|
EiDeletedConstraint
|
VEN
|
VTN
|
|
|
EiConstraint
|
EiRequestConstraint
|
EiSentConstraint
|
VEN
|
VTN
|
To ensure that the VTN constraints match the VEN
description or for recovery
|
The class EiConstraintBehavior
defines how an issued EiEvent that conflicts with the current EiConstraint 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.
·
RESTRICT – modify the EiEvent parameters so that they fall within
the bounds of the EiConstraint
Figure 9‑1: UML Class Diagram for the EiConstraint and Associated Classes
The [UML] class diagram
describes the payloads for the EiConstraint service operations.
Figure 9‑2: UML Class Diagram for EiConstraint Service Operation Payloads
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
|
Operation
|
Response
|
Service Consumer
|
Service Provider
|
Notes
|
|
EiOptout
|
EiCreateOptoutState
|
EiCreatedOptoutState
|
VEN
|
VTN
|
|
|
EiOptout
|
EiChangeOptoutState
|
EiChangedOptoutState
|
VEN
|
VTN
|
|
|
EiOptout
|
EiDeleteOptoutState
|
EiDeletedOptoutState
|
VEN
|
VTN
|
|
|
EiOptout
|
EiRequestOptoutState
|
EiSentOptoutState
|
VEN
|
VTN
|
|
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.
Figure 9‑3: UML Class Diagram for the EiOptout Class
The [UML] class
diagram describes the payloads for the EiOptout service operations.
Figure 9‑4: UML Class Diagram for EiOptout Service Operation Payloads
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
|
Operation
|
Response
|
Service Consumer
|
Service Provider
|
Notes
|
|
EiStatus
|
EiRequestStatus
|
EiSentStatus
|
VEN
|
VTN
|
Status of Assets associated with a VEN
|
|
|
|
|
|
|
|
Figure 9‑5: UML Class Diagram for the EiStatus Class
The [UML] class
diagram describes the payloads for the EiStatus service operations.
Figure 9‑6: UML Class Diagram for EiStatus Service Operation Payloads
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: http://collaborate.nist.gov/twiki-sggrid/pub/SmartGrid/SGTCCIPRM/SGTCC_IPRM_Version_1.0.pdf
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.
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.
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.
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
The following individuals have participated in the creation
of this specification and are gratefully acknowledged:
Participants:
Hans Aanesen, Individual
Bruce Bartell, Southern California Edison
Timothy Bennett, Drummond Group Inc.
Carl Besaw, Southern California Edison
Anto Budiardjo, Clasma Events, Inc.
Edward Cazalet, Individual
Joon-Young Choi, Jeonju University
Kevin Colmer, California Independent System
Operator
Toby Considine, University of North Carolina
William Cox, Individual
Sean Crimmins, California Independent System
Operator
Phil Davis, Schneider Electric
Sharon Dinges, Trane
Robert Dolin, Echelon Corporation
Rik Drummond, Drummond Group Inc.
Ernst Eder, LonMark International
Thomas Ferrentino, Individual
Craig Gemmill, Tridium, Inc.
Girish Ghatikar, Lawrence Berkeley National
Laboratory
Gerald Gray, Southern California Edison
Anne Hendry, Individual
Thomas Herbst, Cisco Systems, Inc.
David Holmberg, NIST
Gale Horst, Electric Power Research Institute
(EPRI)
Ali Ipakchi, Open Access Technology
International Inc. (OATi)
Oliver Johnson, Tendril Networks, Inc.
Sila Kiliccote, Lawrence Berkeley National
Laboratory
Ed Koch, Akuacom Inc
Michel Kohanim, Universal Devices, Inc.
Larry Lackey, TIBCO Software Inc.
Derek Lasalle, JPMorganChase
Jeremy Laundergan, Southern California Edison
Benoit Lepeuple, LonMark International
Edgardo Luzcando, Midwest ISO and ISO/RTO
Council (IRC)
Carl Mattocks, Individual
Dirk Mahling, CPower
Kyle Meadors, Drummond Group Inc.
Scott Neumann, Utility Integration Solutions
Inc.
Robert Old, Siemens AG
Mary Ann Piette, Lawrence Berkeley National
Laboratory
Donna Pratt, New York ISO and ISO/RTO Council
(IRC)
Ruchi Rajasekhar, Midwest Independent System
Operator
Jeremy Roberts, LonMark International
Anno Scholten, Individual
Pornsak Songkakul, Siemens AG
Jane Snowdon, IBM
Aaron Snyder, NIST
William Stocker, New York ISO and ISO/RTO
Council (IRC)
Pornsak Songkakul, Siemens AG
Robert Stayton, Individual
Jake Thompson, EnerNOC
Matt Wakefield, Electric Power Research
Institute (EPRI)
Douglas Walker, California Independent System
Operator
Evan Wallace, NIST
Dave Watson, Lawrence Berkeley National
Laboratory
David Wilson, Trane
Leighton Wolffe, Individual
Brian Zink, New York Independent System Operator
The Technical Committee also acknowledges the work of the
contributing groups who did so much to bring requirements and use cases to the
attention of the Committee. In particular, the ISO/RTO Council task force on
Demand Response, the UCAIug OpenSG Task Force on OpenADR, and the NAESB Smart
Grid Task Force provided invaluable guidance and frequent feedback.
The following individuals have participated in the creation
of this specification and are gratefully acknowledged:
UCAIug OpenSG OpenADR Task Force:
Albert Chiu, Pacific Gas & Electric
Bruce Bartell, Southern California Edison
Gerald Gray, Southern California Edison
The ISO / RTO Council Smart Grid Standards Project:
We want to thank the IRC team, in particular those who
directly participated in this Technical Committee:
Edgardo Luzcando, Midwest ISO and ISO/RTO Council
(IRC)
Donna Pratt, New York ISO and ISO/RTO Council
(IRC)
William Stocker, New York ISO and ISO/RTO Council
(IRC)
The IRC team consisted of a large group of participants from
ISOs and RTOs. See the IRC Smart Grid Standards web site for additional details
about the project and team members -
http://www.isorto.org/site/c.jhKQIZPBImE/b.6368657/k.CCDF/Smart_Grid_Project_Standards.htm
NAESB Smart Grid Standards Development Subcommittee
Co-chairs:
Brent Hodges, Reliant
Robert Burke, ISO New England
Wayne Longcore, Consumers Energy
Joe Zhou, Xtensible Solutions
|
Revision
|
Date
|
Editor
|
Changes Made
|
|
1.0 WD 01
|
|
Toby Considine
|
Initial document, largely derived from OpenADR
|
|
1.0 WD 02
|
|
Toby Considine
|
|
|
1.0 WD 03
|
|
Toby Considine
|
|
|
1.0 WD 04
|
|
Toby Considine
|
|
|
1.0 WD 05
|
|
Toby Considine
|
|
|
1.0 WD 06
|
|
Toby Considine
|
|
|
1.0 WD 07
|
|
Toby Considine
|
|
|
1.0 WD 08
|
2010-03-09
|
Toby Considine
|
Reduced core functions to two service groups,
transactional energy and eliminated references to managed energy
|
|
1.0 WD 09
|
2010-03-23
|
Toby Considine
|
|
|
1.0 WD 10
|
2010-05-11
|
William Cox
|
Updated interaction model per analysis and drawings in TC
meetings in April and early May
|
|
1.0 WD 11
|
2010-05-18
|
William Cox and
David Holmberg
|
Improved model; editorial and clarity changes. Addressed
comments on interaction and service model from TC meetings in May 2010.
|
|
1.0 WD 12
|
2010-05-21
|
William Cox
|
Editorial and content corrections and updates. Consistency
of tone; flagged portions that are more closely related to EMIX.
|
|
1.0 WD 13
|
2010-08-31
|
Toby Considine
Ed Cazalet
|
Recast to meet new outline, Removed much of the
“marketing” content or moved, for now, to appendices. Re-wrote Sections 2, 3.
Created placeholders in 4, 5,6 for services definitions.
|
|
1.0 WD 14
|
2010-10-31
|
William Cox
|
Completed service descriptions and restructured the middle
of the document. Completed the EiEvent service and included UML diagrams.
Deleted no longer relevant sections.
|
|
1.0 WD 15
|
2010-11-15
|
William Cox
Toby Considine
|
Re-wrote sections 5, 7. Re-cast and combined to divergent
sections 3. Misc Jira responses
|
|
1.0 WD 16
|
2010-11-18
|
William Cox
|
Added missing Section 6
|
|
1.0 WD 17
|
2010-11-22
|
Toby Considine,
William Cox
|
Responded to many comments, added Program Services, added
description of Resources and EMIX and WS-Calendar (4). Added Glossary
|
|
1.0 WD 18
|
2010-11-24
|
Toby Considine
|
Responded to formal comments
Added additional language on WS-Calendar
Incorporated missing ProgramCall
Added Simple Market Model to Interactions
|
