Energy Market Information Exchange (EMIX) Version 1.0
Committee Specification Draft 01 /
Public Review Draft 01
15 November 2010
Specification URIs:
This Version:
http://docs.oasis-open.org/emix/emix/v1.0/csprd01/emix-v1.0-csprd01.html
http://docs.oasis-open.org/emix/emix/v1.0/csprd01/emix-v1.0-csprd01.doc (Authoritative)
http://docs.oasis-open.org/emix/emix/v1.0/csprd01/emix-v1.0-csprd01.pdf
Previous Version:
N/A
Latest Version:
http://docs.oasis-open.org/emix/emix/v1.0/emix-v1.0.html
http://docs.oasis-open.org/emix/emix/v1.0/emix-v1.0.doc
http://docs.oasis-open.org/emix/emix/v1.0/emix-v1.0.pdf
Technical Committee:
OASIS Energy Market Information Exchange TC
Chair(s):
Ed Cazalet,
William T. Cox
Editor(s):
Toby Considine
Related work:
This specification replaces or supersedes:
This specification is related to:
Declared XML Namespace(s):
http://docs.oasis-open.org/ns/emix
http://docs.oasis-open.org/ns/emix/power
http://docs.oasis-open.org/ns/emix/power/contract
http://docs.oasis-open.org/ns/emix/power/quality
http://docs.oasis-open.org/ns/emix/power/resource
http://docs.oasis-open.org/ns/emix/power/transport
Abstract:
The data models and XML vocabularies defined by this TC will address issues in energy markets and the Smart Grid, but may be defined so as to support requirements for other markets. The TC will develop a data model and XML vocabulary to exchange prices and product definitions for transactive energy markets.
· Price information
· Bid information
· Time for use or availability
· Units and quantity to be traded
· Characteristics of what is traded
The definition of a price and of other market information exchanged depends on the market context in which it exists. It is not in scope for this TC to define specifications for markets, nor how prices are determined, nor the mechanisms for interoperation. The TC will coordinate with others to ensure that commonly used market and communication models are supported.
Status:
This document was last revised or approved by the Energy Market Information Exchange Technical Committee on the above date. The level of approval is also listed above. Check the “Latest Version” or “Latest Approved Version” location noted above for possible later revisions of this document.
Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at http://www.oasis-open.org/committees/emix/.
For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (http://www.oasis-open.org/committees/emix/ipr.php.
Citation Format:
When referencing this specification the following citation format should be used:
EMIX-v1.0 OASIS Committee Specification Draft 01, Energy Market Information Exchange (EMIX) Version 1.0, November 2010. http://docs.oasis-open.org/emix/emix/v1.0/csd01/emix-v1.0-csd01.doc
Notices
Copyright © OASIS® 2010. All Rights Reserved.
All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.
OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.
OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.
The names "OASIS" and “EMIX” are trademarks of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.
Table of Contents
2.5 Tenders and Transactions for Power Products and Resource Capabilities
3 Overview of the Information Elements
5 EMIX Electrical Energy and Power Product Descriptions
5.1 Taxonomy of EMIX Power Product Descriptions
5.1.1 Power Product Descriptions
5.1.2 Resource Offer Descriptions
5.1.3 Transport Product Descriptions
6.1 Transactive Power Product Description.
6.2 Requirements Power Product Descriptions
6.3 Semantics of Power Products
7.3 Resource Capability Descriptions
7.3.1 Load Curtailment Resource Capability Descriptions
7.3.2 Generation Resource Capability Description
9.1.1 Electrical Power Quality
B. Notes on Ancillary Services (non-normative)
C. Electrical Power and Energy
Tables, Figures & Examples
Figure 7‑1: Attributes of a Generic Resource
Figure 7‑2: Equivalence of Load Shed and Generation
Figure 7‑3: Combining Response Capabilities
Figure 7‑4: Ramp Rate Curve—CIM Style
Table 3‑1: Intrinsic Elements - the "Face of the Envelope"
Table 3‑2: Extrinsic Elements - "Contents of the Envelope"
Table 3‑3: Examples of Warrant Information
Table 3‑4: Option Elements – another "Face of the Envelope"
Table 4‑1: EMIX Product Elements
Table 4‑2: EMIX Product Elements
Table 6‑1: Power Interval Description
Table 6‑2: Power Gluon Description
Table 6‑3: Requirements Power Products
Table 6‑4: Requirements Power Product Description.
Table 6‑5: Requirements Power Product Description.
Table 6‑6: Demand Charges Information Model
Table 6‑7: Simple Elements for use in Power Products
Table 6‑8: Compound Elements for use in Power Products
Table 7‑1 Semantics for Power Resources
Table 7‑2 Semantics for Voltage Regulation Services
Table 7‑3 Responsive Load Resource – Simple Form..
Table 7‑4 Offer Load Reduction
Table 7‑5 Registered Generation Capabilities
Table 7‑6 Power Offer Capabilities
Table 8‑1 Power Regulation Product Description
Table 8‑2 Reserves Product Description
Table 10‑1: Transport Description
This document defines a set of messages to communicate Price and Product definition for power and energy markets. Product definition includes quantity and quality of supply as well as attributes of interest to consumers distinguishing between power and energy sources. Energy Market Information Exchange (EMIX) is not intended as a stand-alone signal; rather, it is anticipated to be used for information exchange in a variety of market-oriented interactions.
The Energy Market Information Exchange Technical Committee (TC) is developing this specification in support of the US Department of Commerce National Institute of Standards and Technology (NIST) NIST Framework and Roadmap for Smart Grid Interoperability Standards [NIST] and in support of the US Department of Energy (DOE) as described in the Energy Independence and Security Act of 2007 (EISA 2007) [EISA].
This specification defines the following:
· The characteristics of power and energy that along with price define a product
· An information model for Price and Product definition using the Unified Modeling Language [UML]
· An XML Schema for Price and Product definition
Key to reading the document:
· BOLD terms are the names of referenced standards
· Italic phrases are quotes from external material.
· [bracketed] are references to the standards listed in listed in the normative or non-normative sections references sections.
· All examples and all Appendices are non-normative.
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].
This information exchange was developed primarily by integrating requirements and use cases for Price and Product definition developed by the North American Energy Standards Board (NAESB) as part of its response to NIST Priority Action Plan 03 (PAP03), “Develop Common Specification for Price and Product Definition” [PAP03], which was driven by NIST, Federal Energy Regulatory Commission (FERC), and DOE priority items.
Where appropriate, semantic elements from the International Electrotechnical Commission (IEC) Technical Committee (TC) 57 Power systems management and associated information exchange Common Information Model (CIM) are used [IEC]. Business and market information was borrowed from the financial instruments Common Information Models as described in International Standards Organization (ISO) [ISO20022] standard and in the financial trading protocol, [FIX] (Financial Information eXchange).
Energy markets are volatile, so precise time of delivery is always a significant component of product definition. EMIX incorporates schedule and interval communication interfaces from Web Services Calendar ([WS-Calendar]) to communicate schedule-related information.
Additional guidance was drawn from subject matter experts familiar with the design and implementation of enterprise and other systems that may interact with smart grids.
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.
RFC5545 B. Desruisseaux Internet Calendaring and Scheduling Core Object Specification (iCalendar), http://www.ietf.org/rfc/rfc5545.txt, IETF RFC 5545, September 2009.
Calendar Product Schema C. Joy, C. Daboo, M Douglas, Schema for representing Products for calendaring and scheduling services, http://tools.ietf.org/html/draft-cal-Product-schema-00, (Internet-Draft), April 2010.
CEFACT Currency codes, e.g. USD or GBP. Add full reference citation to CEFACT or UBL profile of CEFACT
Stoft S. Stoft, Power System Economics: Designing Markets for Electricity. Piscataway, NJ: IEEE Press, 2002.
UML Unified Modeling Language (UML), Version 2.2, Object Management Group, February, 2009. http://www.omg.org/technology/documents/formal/uml.htm .
WS-Calendar OASIS WS-Calendar Technical Committee, specification in progress
xCal C. Daboo, M Douglas, S Lees xCal: The XML format for iCalendar, http://tools.ietf.org/html/draft-daboo-et-al-icalendar-in-xml-05, Internet-Draft, April 2010.
XLINK XML Linking Language (XLink) Version 1.1. S DeRose, E Maler, D Orchard, N Walsh, http://www.w3.org/TR/xlink11/ May 2010.
XPOINTER S DeRose, E Maler, R Daniel Jr. XPointer xpointer Scheme, http://www.w3.org/TR/xptr-xpointer/ December 2002.
XML Schema PV Biron, A Malhotra, XML Schema Part 2: Datatypes Second Edition, http://www.w3.org/TR/xmlschema-2/ October 2004.
EISA Energy Independence and Security Act (EISA), online. Link retrieved 06/23/2010: http://www.nist.gov/smartgrid/upload/EISA-Energy-bill-110-140-TITLE-XIII.pdf
FIX The FIX protocol (need formal reference)
IEC TC57 The home of the IEC TC 57 is http://tc57.iec.ch/index-tc57.html (link retrieved 06/23/2010)
ISO20022 International Standards Organization, ISO 20022 (need full reference)
TeMIX Transactional Energy Market Information Exchange [TeMIX] an approved White Paper of the EMIX TC. Ed Cazalet et al. http://www.oasis-open.org/committees/download.php/37954/TeMIX-20100523.pdf
NAESB 03 Requirements Specification for Common Electricity Product and Pricing Definition, North American Energy Standards Board [NAESB], March, 2010 (Public Review Draft). http://naesb.org/pdf4/weq_2010_ap6a_retail_2010_ap9a_rec.doc
NIST Roadmap NIST Framework and Roadmap for Smart Grid Interoperability Standards, Release 1.0, online. Link retrieved 06/23/1010: http://www.nist.gov/public_affairs/releases/upload/smartgrid_interoperability_final.pdf
PAP03 Details of PAP03 may be found at http://collaborate.nist.gov/twiki-sggrid/bin/view/SmartGrid/PAP03PriceProduct (link retrieved 06/23/2010)
White Paper on WS-Calendar Link to final paper 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 lower camelCase convention, with all names starting with a lower case letter. For example,
<element name="componentType" type="energyinterop:ComponentType"/>
For the names of types within XSD files, the names follow the lower CamelCase convention with all names starting with a lower case letter prefixed by “type-“. For example,
<complexType name="type-componentService">
For the names of intents, the names follow the lower camelCase convention, with all names starting with a lower case letter, EXCEPT for cases where the intent represents an established acronym, in which case the entire name is in upper case.
An example of an intent that is an acronym is the "SOAP" intent.
For readability, element names in tables appear as separate words. The actual names are lowerCamelCase, as specified above, and as they appear in the XML schemas.
All elements in the tables not marked as “optional” are mandatory.
Information in the “Specification” column of the tables is normative. Information appearing in the note column is explanatory and non-normative.
Energy markets have been characterized by tariffs and embedded knowledge that make decision automation difficult. Smart grids introduce rapidly changing products and product availability, with associated dynamic prices. Lack of standardized of messages conveying market information has been a barrier to development and deployment of technology to respond to changing market circumstances.
Price and product definition are actionable information. When presented with standard messages conveying price and product, automated systems can make decisions to optimize energy and economic results. In regulated electricity markets, price and products often are defined by complex tariffs, derived through political processes. These tariffs convey the price and product information to making buying and selling decisions easier. The same information can be derived from market operations in non-tariffed markets. EMIX defines the information for use in messages that convey this actionable information.
An essential distinction between energy and other markets is that price is strongly influenced by time of delivery. Energy for sale at 2:00 AM, when energy use is low, is not the same product as energy for sale at the same location at 2:00 PM, during the working day. EMIX conveys time and interval by incorporating WS-Calendar into tenders, contracts, and performance calls.
Not all market information is available in real time. Present day markets, particularly wholesale markets, may have deferred charges (e.g. balancing charges) that cannot be determined at point of sale. Other markets may require additional purchases to allow the use of the energy purchased (e.g. same-time transmission rights or pipeline fees when accepting delivery on a forward contract). EMIX is useful for representing available price and product information/
The OASIS Energy Market Information Exchange Technical Committee (EMIX TC) has prepared a white paper which paper provides a context for discussing the use of transactions in retail and wholesale energy markets. The Transactional Energy Market Information Exchange (TeMIX) white paper can be found in the non-normative references.
Energy is a commodity whose market value may be different based upon how it is produced or generated. After production, though, the commodity is commingled with production from other sources with which it is fully fungible. Even so, some energy purchasers distinguish between sources of this product even as they consume the commingled commodity.
Throughout this work, we refer to the intrinsic and extrinsic properties of an energy product. An intrinsic property is one “belonging to a thing by its very nature.”[1] An extrinsic property is one “not forming an essential part of a thing or arising or originating from the outside.”[2] In EMIX, the term intrinsic properties refers to those that can be measured and / or verified at the point of delivery, i.e., electric power and price. The term extrinsic properties refers to those that can only be known with prior knowledge, such as the carbon cost, the energy source, or the sulfate load from generation.
EMIX messages communicate both intrinsic and extrinsic properties; extrinsic properties must be able to clear in the market just as does intrinsic energy.
As a conceptual aid, we discuss the information structure using the metaphor of an envelope containing warrants. The intrinsic properties and the price are on the face of the envelope, easy to read by all. The contents of the envelope are the supporting information and various warrants about the extrinsic qualities.
On the face of the envelope, EMIX lists the intrinsic qualities of the energy product. In the simplest model, the intrinsic qualities are limited to the price and the information a meter can provide. In a market of homogenous energy sources and commodity energy, only the intrinsic qualities are actionable. In postal handling, information on the face is meant for high-speed automated processing. The simplest devices, including the proverbial smart toaster[3], may understand only the intrinsic qualities. The Committee anticipates that the information on the face of the envelope will be sufficient for many if not most energy decisions.
The envelope contents are the supporting documents that explain and justify the price for the intrinsic qualities. These extrinsic qualities are separable from the intrinsic transaction and traded in secondary markets. The contents can include Warrants about the source and the environmental attributes provide information about the energy, but they are not the energy. The extrinsic qualities enable traceability and auditing, increasing public trust in energy markets and on energy differentiation. The simplest gateways and devices may ignore the warrants, that is, they can forward or process messages without opening the envelope.
Extrinsic information conveyed by the envelope includes supporting information. For example, a purchaser may opt to buy energy from a particular supplier with advertised rates. Transport loss may reduce the quantity delivered. Markets may add congestion charges along the way. Such supporting information can explain why the delivered cost, on the face of the envelope, is different than the purchase cost.
Time is an important component of energy product transactions. A product produced in one interval of time may have to be stored or may not be able to be stored for a later interval of time. Thus the same product in different intervals of time may have different prices. EMIX uses [WS-Calendar] to apply prices and products to time intervals.
WS-Calendar defines a mechanism to apply a schedule to a sequence of time intervals. WS-Calendar further defines how to use a process analogous to inheritance to apply a single information artifact to each interval in the sequence, allowing elements of that artifact to be over-ridden within any given interval. WS-Calendar also defines a schedule entry point, defining how specific performance can be contracted and scheduled.
This document assumes that the reader has a clear understanding of WS-Calendar and its interfaces. The non-normative white paper on the use of the WS-Calendar specification published by that committee is a good place to start.
The focus of EMIX is on price and product communication in support of commercial transactions. The messaging and interaction patterns for commercial transactions are out of scope for EMIX but worth a brief discussion here to provide context.
Transactions in most markets begin with Tenders (offers to buy or sell) by a Party to another Party. Once an agreement among Parties is reached, the parties agree to a Transaction (contract or award). The parties to the Transaction then must perform on the Transaction by arranging for supply, transport, consumption, settlement and payment. At every stage in this process, clear communication of the terms (price, quantity, delivery schedule and other attributes) of the tender or transaction is essential. Section 3, “Overview of the Information Elements” describes EMIX Terms, the core of EMIX-based communications.
In many electricity markets Operators are offered electrical products based on specific resources, i.e., generators, load curtailment, and other energy resources. EMIX uses EMIX Resource Descriptions to describe the responsiveness, capacity, and other aspects of these Resources. EMIX Resource Offers combine an EMIX Resource Description with a multi-part offer. A Party can use EMIX Resource Offers to tender to an Operator one or more EMIX Products. Similarly, an EMIX Load Curtailment Offer combines a Load Curtailment Resource Description with a multi-part offer.
Product Transport incurs specific costs that vary over time. Delivery costs come in two general forms. Congestion charges apply to each unit of Product that passes through a particular point in the distribution system. Congestion charges increase the cost of the Product delivered in a particular Interval. Loss reduces the Product delivered below the amount contracted for as it passes from the purchase point to the delivery point. Loss may reduce the amount of Product received or a loss change may be applied to purchase replacement energy for the energy loss.
If the Product is priced for Delivery to the consumer, transport charges may not apply. Product descriptions for Transport charges are discussed in Section 10, Power Transport Products.
Many products, particularly those transacted for Demand Response, are distinguished by particular Verification Methods. In a pure transactive energy market, the meter would be the only Verification mechanism. In today’s markets, Verification can be more complex.
Verification is out of scope for this document. Verification is fully specified under NAESB Business Practices for Verification. This specification does not describe verification.
EMIX supports a modular model in which extensions to EMIX can easily be propagated into standards the communicate EMIX. There are multiple EMIX envelopes to participate in different roles; each includes a set of EMIX Terms that describe what is tendered or transacted. EMIX Terms are described by applying an EMIX Product Description to a WS-Calendar Sequence.
New efforts could specify additional Product Descriptions. These new product Descriptions would generate new EMIX Terms merely by applying the new Product Descriptions to the WS-Calendar Sequence. Such Products could then be transported on any EMIX Envelope. Any Specification that communicates EMIX Terms can then communicate market information about these new Product Descriptions. A new committee can extend EMIX into new products without re-considering any aspects of the EMIX specification itself.
A similar logic applies to the warrants, which are not specified in v1.0. If the warrant information varies over time, the warrant information can be applied to a WS-Calendar sequence just as if it were a Product Description.
EMIX describes the Terms (EMIX Terms) of tenders and transactions for products whose markets are volatile. An energy product typically is delivered over time at a specific location. Five kW at 2:00 AM does not provide the same energy services as five kW at 2:00 PM. EMIX describes the terms of tenders and transactions for which time and location are essential characteristics. For example, the price and quantity (rate of delivery) of energy in each time interval of a sequence of intervals may vary for energy transactions made in a sequence of intervals.
EMIX Terms are defined by applying Product Descriptions to WS-Calendar Sequences. WS-Calendar Sequences embody the same calendaring standards used by most business and personal calendaring systems. This enables greater interoperation between grid systems and business and personal systems. An EMIX Product Description describes the elements of an energy product at a location for one time interval or a sequence of time intervals. An EMIX Product Description for a constant rate of delivery power product over a single interval of time comprises a (1) start time, (2) duration, (3) rate of delivery, (4) price and (5) location. If the rate of delivery (kW) and price ($/kWh) have been messaged in advance, the message to deliver the product is simply “start (reference Uri to product) at 3:00 AM for 0.75 hours.”
A Product Description included in each interval in a sequence could describe the same elements again and again. Only a few elements, perhaps only price, or quantity, may change per interval. EMIX uses the WS-Calendar Sequence to specify product elements once, and then specifies which elements may vary by the time intervals of a sequence.
For example, a responsive load may require 15 minutes lead time between notification and load reduction. This characteristic may hold true whether the response requested is for a run-time of 10 minutes or for 10 hours. EMIX specifies these invariant characteristics as part of a product, while offering the variable run-time to the market.
EMIX Terms using EMIX Product Descriptions applied to WS-Calendar Sequence provide a very flexible information model for describing any energy tenders or transaction. New or specialized energy products can offered and transacted without changing the EMIX standard.
EMIX Terms also minimize the size of EMIX-based messages by efficiently describing how information elements of a tender or a transaction may or may not vary over time. This reduces communication overhead.
The following table (Table 3‑1) specifies the Intrinsic Elements in the EMIX information model. Intrinsic elements make up the face of the envelope.
Table 3‑1: Intrinsic Elements - the "Face of the Envelope"
Intrinsic Element |
Specification |
Note |
Uid |
Identifier of this artifact |
|
Created date time |
Datetime this artifact was produced |
|
Transactive State |
Enumerated string |
Used to aid parsing and conformance, e.g., to distinguish between tender and transactive communications |
Terms |
EMIX Terms artifact as defined in later sections of this specification |
EMIX Terms describe the product/ commodity, the location and delivery intervals. EMIX Terms are constructed by the application of a Product Description to the gluons and intervals of a WS-Calendar Sequence. In the simplest case of direct specification of an interval, with no gluon, this leaves only the product description, the performance time, and the duration |
Price |
Float. (Optional) |
Is the sum of the extended price of intervals only if the intervals are purchased as a single tender or transaction. |
Package Discount |
Float (Optional) |
There may be market reasons for the price to be different than the Extended Price |
Market Context |
Xs:anyUri. An identification of the market in which the product is offered. |
This may include standard financial and energy exchanges, markets managed by system operators, markets managed by or for aggregators and distributors, and an identification of the microgrid in which the product is priced. |
Party |
Xs:anyUri. An identifier for one of the parties to a tender or transaction. |
|
CounterParty |
Xs:anyUri. An identifier for one of the parties to a tender or transaction. |
|
Side |
The role (buyer or seller) of the Party. The Counterparty takes the other role. |
|
Currency |
A code that indicates the currency used, as specified in [CEFACT] |
Examples include USD, CAD, GBP, EUR, CNY. Could be a nominative or shadow price referenced to e.g. microgrids |
Extrinsic elements are those that are not inherent to the nature of the product. Customers or regulations may value them, and they may affect the price received on the market for a product. Extrinsic elements are contained within the envelope.
Table 3‑2 lists defines contents of the envelope, i.e., the extrinsic elements in the EMIX information model. These items are in the general from of an EMIX Product Description, and can be elaborated using EMIX Terms if there is a time element to its information.
Table 3‑2: Extrinsic Elements - "Contents of the Envelope"
Extrinsic Element |
Specification |
Note |
Envelope |
Optional. Container for extrinsic information as defined in the next section. |
The envelope contains supporting information that goes beyond that natively in the transaction or tender. |
Warrant List |
The container for array of warrants. Optional. |
An array of the warrants included in the envelope. See section 4 for warrants. |
Support of Price |
Container holding information supporting price information |
May include EMIX Terms, if several are combined to produce the intrinsic price. |
Program |
A possibly structured name for a program in which the price and product are tendered or transacted. |
This may be analogous to a contract identifier. The variety of DR “programs” inspired this proposed element. |
EMIX anticipates that further elements will be defined, and an EMIX envelope containing other elements is fully compliant.
The definition of a warrant is “a written assurance that some product or service will be provided or will meet certain specifications”[4]. Sellers use EMIX Warrants to provide information about the source of the energy or about its environmental characteristics. Buyers can use warrants to indicate what they wish to purchase. It seems a fundamental market rule that a middleman cannot sell more wind power than he has bought. Such rules are beyond the scope of EMIX, but EMIX-based information exchanges are designed to support such market rules.
EMIX Warrants are assertions about the EMIX Terms.
There is a wide variety of warrant types, issuing authorities, and characteristics described by warrants. For bilateral agreements, there may be self-issued warrants. In larger markets, there may be a requirement that Warrants be traceable through multiple levels of transactions.
Table 3‑3: Examples of Warrant Information
Warrant Element |
Specification |
Note |
Quality Warrant |
A Product-specific assertion of Quality. For Electric Power products, these are based upon [IEEE 1159]-based metrics. |
For a tender, this can be a promise of or requirement for quality. For verification, this can be actual measurements. If during an indication of interest, might be a desired minimum standard. |
Environmental Warrant |
An enumeration of the environmental burden caused by the production of the energy product in the quantity and units indicated |
The initial EMIX standard included a non-normative artifact contributed by the Energy Information Standards Alliance (EIS Alliance). It is anticipated that markets will create environmental warrants relevant to their unique needs. |
Content Warrant |
A warrant about the means of production for the energy. These may be used to warrant the content of storage, as the nature of the original input to storage is not altered when drawn from storage. |
The proportion of the product defined that is from non-fossil fuel sources, including but not limited to “hydroelectric”, “solar”, and “wind”. |
Source Warrant |
Individual source warrants |
In aggregate may be the same as Content Warrant |
Controllability Warrant |
An authority warrants that a resource can be controlled to the standards used by that authority |
Usually a prerequisite for participation in direct control contracts. |
The EMIX Option is a variation on the EMIX envelope described above in section “The Intrinsic Elements”. An option gives the buyer the right, but not the obligation, to buy or sell a product at a set price during given time windows. The EMIX option also specifies specific response times. The “face of the envelope” displays additional information to support these requirements.
Table 3‑4: Option Elements – another "Face of the Envelope"
Intrinsic Element |
Specification |
Note |
Uid |
Identifier of this artifact |
The format of this ID varies by the communication is is intended for. For wider markets, the UID should be globally unique. |
Created date time |
Datetime this artifact was produced |
|
Transactive State |
Enumerated string |
Used to aid parsing and conformance testing, e.g., to distinguish between tenders, transactions, and history. |
Terms |
EMIX Terms artifact as defined in later sections of this specification |
EMIX Terms describe the product/ commodity, the location and delivery intervals. EMIX Terms are constructed by the application of a Product Description to the gluons and intervals of a WS-Calendar Sequence. In the simplest case of direct specification of an interval, with no gluon, this leaves only the product description, the performance time, and the duration |
Option Exercise Schedule |
Vcalendar collection (from [ICalendar]) |
An option may specify the period or periods in which the option is available for exercise. For example, a reserve power option could specify a schedule of afternoons in July. |
Option Holder Party |
Xs:anyUri |
The party which enjoys the benefit of choosing whether or not to exercise the terms specified in the option. The Promisee. |
Option Premium |
EMIX Price |
The price paid to the Promisor for the rights involved |
Option Strike Price |
EMIX Price |
The price at which an option holder ( Promisee ) has the right to require the option writer (Promisor) to deliver. |
Option Exercise Delivery Time |
duration |
An EMIX Option specifies required lead time before the response as well as the ability to deliver. |
Extended Price |
EMIX Price. The sum of all intervals in the Product above. (Optional) |
Is the sum of the extended price of intervals only if the intervals are purchased as a single tender or transaction. |
Package Discount |
EMIX Price. (Optional) |
There may be market reasons for the price to be different than the Extended Price |
Market Context |
Xs:anyUri. An identification of the market in which the product is offered, or the counterparty if part of a bilateral non-market transaction. (Optional) |
This may include standard financial exchanges, markets managed by or for aggregators and distributors, and an identification of the microgrid in which the product is priced. |
Currency |
A code that indicates the currency used, as specified in [CEFACT] |
Examples include USD, CAD, GBP, EUR, CNY. Could be a nominative or shadow price referenced to e.g. microgrids |
Envelope |
Container for extrinsic information as defined in the next section. (Optional). |
The envelope contains supporting information that goes beyond that natively in the transaction or tender. |
The generic EMIX Terms are defined by a set of EMIX Elements as described in Table 4-1. The Generic Terms become specific when a Product Description is applied to the Generic Terms. Specific Product Descriptions contain additional EMIX Elements as described Section 5 through 10.
This section also indicates how information from the product description, along with price and quantity, is applied to the gluon and interval. Schedule information can be applied to each as described in [WS-Calendar]
Table 4‑1: EMIX Product Elements
Product Element |
Specification |
Note |
Product Description |
Emix.ProductDescription object |
An EMIX ProductDescription describes the energy or services, the location and the price and quantity variables that can be set as a default in the gluon and inherited by the Intervals in the Sequence. Inheritance is as described in [WS-Calendar]. The ProductDescription is an extension of the Artifact that is a part of each Interval and Gluon. |
Gluon Duration |
WS-Calendar duration |
Sets default duration for Intervals in the Sequence. Not known in all interactions and nor present in all Gluons. |
Gluon Quantity |
Float |
Sets default Quantity for all Intervals in the Sequence. Not known in all interactions and nor present in all Gluons. |
Gluon Unit Price |
EMIX Price, Optional |
Sets for all Intervals in the Sequence not otherwise priced. Not known in all interactions and nor present in all Gluons. |
Sequence |
WS-Calendar:Sequence (collection of Intervals) |
A sequential set of Intervals including expression of Price, Quantity, or Both. May also include elements of the Product Description |
Starting DateTime |
Optional |
Only required when scheduling a sequence. Applies to the associated interval— starting times of other intervals are computed from the sequence based on the sequence starting time, the temporal reltions between intervals, and the duration of each. |
Associated Interval |
From WS-Calendar |
Link from the EMIX Gluon into the sequence of Intervals. |
The Gluons point to a set of intervals with defined temporal relationships. An example of intervals with temporal relationships is a set of consecutive intervals. A collection of such intervals is known as a Sequence.
Table 4‑2: EMIX Product Elements
Product Element |
Specification |
Note |
Product |
Emix.ProductDescription object |
Elements of the Product Description that can be inherited without change from the Gluon need not be expressed in the Interval. The ProductDescription is an extension of the Artifact that is a part of each Interval and Gluon. |
Duration |
WS-Calendar duration |
Can be inherited from the Gluon Set |
Quantity |
Float |
Can be inherited from the Gluon Set |
Unit Price |
Float, Optional |
Can be inherited from the Gluon Set |
Starting DateTime |
Optional |
Usually be inherited from the Gluon Set. Only one Interval per sequence gets a Starting DateTime |
Temporal Relation |
From WS-Calendar |
Link from one interval to other intervals in the sequence. |
The illustration below provides a model for how this can work.
Figure 4‑1: EMIX Model
Electrical Energy (measured in MWh, for example) does work. Electrical Power is the rate of delivery of Energy (measured in MW, for example). Often the terms energy and power are used in conversation interchangeably without confusion, for EMIX, precision of language for energy and power is crucial. For convenience, terms associated with electrical power and energy, and the relationships between them, are reviewed in Appendix C.
EMIX Product Descriptions are broken down into the following three classes discussed below:
1) Power Product Descriptions
2) Resource Offer Descriptions
3) Transport Product Descriptions
All EMIX Electrical Power Products are defined using standard attribute definitions from the Power and Load Management Common Information Model (CIM). The canonical definitions are in the IEC TC57 CIM.
Power Products are the subject of tenders and transactions, i.e., they are what is actually bought and sold. Depending upon the market, Power can be bought under terms that specify the energy and its rate of delivery (power), or made available for use up to the maximum amount deliverable by the in-place infrastructure (also known as “Full-requirements Power”) Power Products for transactions are discussed in the rest of this section.
Resources are generators that can produce energy and other services, storage devices that can consume, store and then produce Power Product, and load curtailment contracts that produce a Power Product from load curtailment.
A Resource Offer describes both the characteristics of the resource and the prices and quantities of products and services offered as described in Section 7
Product Transport incurs specific costs that vary over time. Delivery costs come in two general forms. Congestion charges apply to each unit of Product that passes through a particular point in the distribution system. Congestion charges increase the cost of the Product delivered in a particular Interval. Loss reduces the Product delivered below the amount contracted for as it passes from the purchase point to the delivery point. Loss may reduce the amount of Product received or a loss charge may be applied to purchase replacement energy for the energy loss.
If the Product is priced for Delivery to the consumer, transport charges may not apply. Product descriptions for Transport charges are discussed in Section 10, Power Transport Products Descriptions.
The Transactive Power Product Description is based on a simple product description: Power, Price, Attributes, and Service Location. As defined in EMIX, a Power Interval has two potential forms, a ramped power interval and for a constant power interval. A constant power interval uses the power quantity specified locally or one inherited from the Gluon. A ramped power interval cannot inherit the power quantity because it contains two power quantities internally: the starting rate and the final rate. Both interval types are reflected in the table below:
Table 6‑1: Power Interval Description
Name |
Definition |
Note |
Constant Power Quantity |
EMIX.Quantity |
Defines Constant Power Intervals. Does not coexist with Starting and Final Power Quantities |
Starting Power Quantity |
EMIX.Quantity |
Defines Ramped Power Intervals. Requires matching Final Power Quantity. Does not coexist with Constant Quantity |
Final Power Quantity |
EMIX.Quantity |
Defines Ramped Power Intervals. Requires matching Starting Power Quantity. Does not coexist with Constant Quantity |
Power Units |
Power Units |
As defined below |
Service Location |
Service Location |
Should normally be only in the Gluon and omitted from the intervals. If the Product is an aggregated response across multiple locations, one per interval, then it MAY appear in the interval instead |
Power Attributes |
Power Attributes |
As defined below |
UnitPrice |
EMIX.Price |
Price per Unit Quantity. Includes currency |
Price |
EMIX.Price |
Extended price for interval. Includes quantity and currency |
Duration |
From WS-Calendar |
May be nil if inherited from Gluon |
Performance |
From WS-Calendar |
Indicates performance requirements such as fixed run-time, absolute end time, etc. |
The Gluon shares the same information elements with the exception that ramps are not defined for Gluons.
Table 6‑2: Power Gluon Description
Name |
Definition |
Note |
Power Quantity |
EMIX.Quantity |
Defines Constant Power Intervals. Does not coexist with Starting and Final Power Quantities |
Power Units |
Power Units, enum |
As defined below |
Service Location |
Service Location |
If response is for a single location, should be in gluon to apply to the entire sequence and be omitted in the intervals |
Power Attributes |
Power Attributes |
As define below |
Unit Price |
EMIX.Price |
Price per Unit Quantity. Includes currency |
Price |
EMIX.Price |
Extended price for interval. Includes quantity and currency |
Duration |
From WS-Calendar |
May be nil if all intervals have duration specified |
Performance |
From WS-Calendar |
Indicates performance requirements such as fixed run-time, absolute end time, etc. |
No element in the gluon need appear in the interval unless the interval information supercedes the gluon information.
The constant power product is sufficient for all Transactive Energy uses. Many tenders that are offered or solicited as Resources are normally executed, i.e., contracted for performance, as a constant power product. (Ancillary Products are an exception—see section 8.) As the Power Quantity varies over intervals in the sequence, it describes a load curve. As the Price varies over intervals in the sequence, it describes a price curve.
The Requirements Power Product Descriptions below can successfully describe contracted power in use today including
Table 6‑3: Requirements Power Products
Name |
Note |
Full Requirements Power |
Traditional power contract to provide all power used. Often used in retail residential rates. Demand Charges Optional |
Full Requirements Power with Demand Charges |
Often used in mid-sized and small commercial. Same as Full Requirements Power but with demand charges for “excess” use. |
Requirements with Maximum and Minimum Power |
Customer must draw energy at least the minimum rate (power) and no more than the maximum rate during any measurement interval. |
Hourly Day Ahead Pricing |
Same Full requirements power but prices potentially change each day. |
Ex-Ante Real Time Price |
Used to report prices after the fact. |
Time of Use Pricing |
Similar to Hourly day-ahead pricing but prices may change seasonally and not be at hourly intervals |
Contracted power products such as these can all be described using the Contracted Power Product Description
Table 6‑4: Requirements Power Product Description
Name |
Definition |
Note |
Contract Type |
Enumerated String |
|
Power Units |
Power Units |
As defined below |
Service Location |
Service Location |
If response is for a single location, should be in gluon to apply to the entire sequence and be omitted in the intervals |
Power Attributes |
Power Attributes |
As defined below |
Price |
From EMIX |
Price per Unit during the Interval. |
Demand Charge |
Demand Charge. Optional |
See below. There may be multiple demand charges. |
Maximum Power |
Power |
Buyer may not consume at more than this rate |
Minimum Power |
Power |
If buyer consumes than this rate, the buyer is assessed a charge to bring it up to this rate. |
Duration |
From WS-Calendar |
May be nil if all intervals have duration specified |
Performance |
From WS-Calendar |
Indicates performance requirements such as fixed run-time, absolute end time, etc. |
Requirements Power may not match well with future smart energy scenarios. Requirements Power has no fixed forward obligation to take-and-pay for energy. Thus, there is no defined baseline for demand response or dynamic pricing. However, Requirements Power Descriptions are necessary for current legacy communications.
Table 6‑5: Requirements Power Product Description
Name |
Definition |
Note |
Contract Type |
Enumerated String |
|
Block Power Price |
Multiple occurs |
Sequence of components defining the price of successive blocks of power. Each block has a Price, and a maximum energy quantity. If the contract is for an increasing block price, blocks are interpreted in order of increasing price, and for a decreasing block price contract, blocks are interpreted in order of decreasing price |
Power Units |
Power Units |
As defined below |
Service Location |
Service Location |
If response is for a single location, should be in gluon to apply to the entire sequence and be omitted in the intervals |
Power Attributes |
Power Attributes |
As defined below |
Price |
From EMIX |
Price per Unit during the Interval. |
Demand Charge |
Demand Charge. Optional |
See below. There may be multiple demand charges. |
Maximum Power |
Power |
Buyer may not consume at more than this rate |
Minimum Power |
Power |
If buyer consumes than this rate, the buyer is assessed a charge to bring it up to this rate. |
Duration |
From WS-Calendar |
May be nil if all intervals have duration specified |
Performance |
From WS-Calendar |
Indicates performance requirements such as fixed run-time, absolute end time, etc. |
Demand Charges assess additional costs based peak rate of use by the buyer. Demand charges often extend beyond the current billing period.
Table 6‑6: Demand Charges Information Model
Name |
Definition |
Note |
Demand Charge Units |
Power units |
Single units used by all quantities |
Demand Charge Floor |
Quantity |
Above this floor is exceeded, demand charges are applied |
Demand Charge Rate |
Price / Power |
Incremental charge applied power if floor is exceeded. |
Measurement Interval |
Duration |
Granularity or Power Use readings. |
Collection Interval |
Duration |
Period during which power usage is summed for comparison to Demand Floor. |
Collection Period |
Duration |
Usually the same as the billing period |
Charge Duration |
Duration |
Period during which Demand Charges will be applied after incurred. |
The product descriptions refer to terms and data structures that had not yet been defined. These elements are defined below.
First, there are simple base elements used again in defining power products, including those in the next sections.
Table 6‑7: Simple Elements for use in Power Products
Name |
Definition |
Note |
Voltage |
Decimal, May be measured or nominal |
One of three elements hereafter referred to as the Power Attributes. |
Hertz |
Decimal, May be measured or nominal |
One of three elements hereafter referred to as the Power Attributes. Always 0 for DC |
AC |
Boolean, true for AC, false for DC |
One of three elements hereafter referred to as the Power Attributes. |
Power Units |
String |
Enumeration of Power Units, e.g., MW |
Energy Units |
String |
Enumeration of Energy Units, e.g., MWh |
Voltage Units |
String |
Enumeration of Voltage Units, e.g., MV |
VAR Units |
String |
Enumeration of volt amperes reactive (var) units, e.g., Kvar |
Meter Asset |
String |
Identifier for an actual or virtual meter |
Node |
String |
Grid Location identifier |
Often, multiple simple units do or should appear together in specifications for constancy and completeness. These are named and defined as below.
Table 6‑8: Compound Elements for use in Power Products
Name |
Definition |
Note |
Power Attributes |
Voltage / Hertz / Ac |
Group used in many definitions |
Transaction Node |
Node & Meter Asset |
Location of a meter and the Service location the point of interconnection where capacity and/or energy transmitted by the provider is made available to the receiving party. |
Pnode |
Transaction Node |
A pricing location for which market participants submit their bids, offers, buy/sell CRRs, and settle. |
APnode |
Transaction Node |
Aggregated Pnode |
Service Location |
Transaction Node |
For residential or most businesses, it is typically the location of the meter on the utility customer's premises. For transmission, it is the point(s) of interconnection on the transmission provider's transmission system where capacity and/or energy transmitted by the transmission provider is made available to the receiving party. |
Service Place |
Geo-location, i.e. kml:placemark |
Typically a geo-referenced polygon that might contain many transaction nodes |
Interface Pricing Point |
Pnode or APnode or Service Location or Service Place |
Typically the location of the meter on the customer's premises. For transmission, it is the point(s) of interconnection on the transmission provider's transmission system where capacity and/or energy transmitted by the transmission provider is made available to the receiving party. May also be a place containing nodes. |
Resources offer potential services to others in smart grid. Resource tenders are either requesting services or offering services. In a pure transactive market, these tenders might be identical to the services provided, i.e., they could be fully described using the same language used to contract execution and performance.
Resources often enter or are called enter the market to meet specific needs. These needs can include a range of performance requirements; resources might be able to perform a range of capabilities. These performance capabilities are described using the information in Resources Offers. Resource offers are less specific than a single transactive request, and may thereby present the resource to more than a single market.
When making a tender for products and services, it is useful to describe the capabilities of a resource, so the counter party can determine if a resource can meet the requirements. A notice of interest may specify performance expectations. A resource may compare its own capabilities to those requirements before submitting a bid.
Resource Capabilities may describe a ramp rate, or maximum run time, or any number of elements useful to energy schedulers. A Resource Offer associates offers for power produces with a Resource Capability.
Resources have capabilities rather than schedules. Resource descriptions describe what could be done, as distinguished from a transaction in which specific performance is requested or agreed to.
Figure 7‑1: Attributes of a Generic Resource
In the resource illustration above, there is some base level of energy, a status quo ante. When invoked, the resource takes some period of time to change to a different level. If the response is binary, then it can only go up to the maximum response, and that ramp rate takes a fixed time. If a resource is able to provide several layers of response, then the ramp time also varies. The ramp time can be computed from the ramp rate and the difference between the base power and the maximum response.
As electricity is fungible, a critical key element of power resources is that generation, that is the production of power, and load shedding, the reduction of power use are similar products with similar value.
Figure 7‑2: Equivalence of Load Shed and Generation
As shown above, generation and load response are similar and can be described using the same language.
Many resources have capabilities that change over the range of response. A generator may have one ramp speed until it gets up to half speed, and then another as it goes to full. Load response can have similar characteristics. Such resources can be described by combining simple response characteristics.
Figure 7‑3: Combining Response Capabilities
Resources as in Figure 7‑3 can be communicated as an array of ramp up rates, a maximum power offered, and an array of ramp down rates. Between the Base 1 and Maximum 1, expressed in MW, the resource can ramp up at Ramp 1 expressed in MW/min. Between the Base 2 and Maximum 2, expressed in MW, the resource can ramp up at Ramp 1 expressed in MW/min.
With capabilities expressed as above, to capabilities of a resource can be found by the time indicated (moving along the X axis) between Base 1 and wherever the ramp up line passes through desired output level.
CIM users express this with a Ramp Rate Curve. Figure 7‑4 expresses similar information as does Figure 7‑3, showing Base1 at 50 MW of power and Maximum 1 at 100 MW with a ramp rate pf 10 MW/minute. Ramp 2, at 15 MW/minute goes from 100MW to 180 MW.
Figure 7‑4: Ramp Rate Curve—CIM Style
By expressing resources in terms of capabilities and ramp rates, a potential purchaser can determine of a resource meets his or her needs, tendering a single resource to a variety of purchase scenarios.
Picture several resources each able to generate 10 MW of additional power. One can increase power at 1 MW/minute, one at 2 MW/minute, one at 5. MW/minute. The latter two each can be contracted to supply 10 MW in 5 minutes. Only the last can be contracted to supply an increase of 10 MW within 2 minutes. All three can be contracted to supply an increase of 10 MW within 15 minutes.
The only aspects of a resource that matters to the energy market are the effects it can provide, the likelihood it will be able adequately to provide what it promises, and the financial incentives required to acquire them. The technology and process control details are many, and new ones may be required for each new power technology. Unless the market for the resource requires direct control, such details are irrelevant. The limited semantic set herein is sufficient to describe the capabilities of a resource.
EMIX bases its resource capability descriptions on the semantics in Table 7‑1.
Table 7‑1 Semantics for Power Resources
Name |
Definition |
Note |
Mrid |
String |
multi-part resource id as defined in the ISO TC57 CIM uniquely identifies each resource. |
Notification Time |
Duration |
Time required for notification prior to beginning of response. |
Response Time |
Duration |
Time required from notification to full response by the resource |
Minimum Down Time |
Duration |
Minimum time interval between unit shut-down and start-up |
Power Ramp Rate |
Float & Power Units |
Change up or down in units/minute between a starting power and an ending power. |
Required Notice Time |
Duration |
Time period that is required from an order to reduce a load to the time that it takes to get to the minimum load reduction. |
Shutdown Cost |
Price |
The fixed cost associated with committing a load reduction. |
Offer Segment |
Price, |
Compound unit describing components of a tender. If multiple segments are offered (1st 50MW, next 100MW), Maximum Power is cumulative (50MW, 150MW). Offers are evaluated by sorting in order of increasing Maximum Power (for power) or decreasing Maximum Power (for load reduction) and must be purchased in order. |
Minimum Resource Cost |
Price per Duration |
Resource requires this amount per period, i.e., a minimum requirement for $100 / hour at whatever power rate |
Minimum Time Between Load Reductions |
Duration |
Shortest time that load must be left at normal levels before a new load reduction. |
Minimum Load Reduction Interval |
Duration |
Shortest period load reduction must be maintained before load can be restored to normal levels. |
Minimum Load Reduction |
Power |
Minimum units for a load reduction (e.g., MW rating of a discrete pump) |
Minimum Load Reduction Cost |
Price |
Cost in currency at the minimum reduced load |
Maximum Operating Power |
power quantity |
The maximum operating power the purchaser can request from this unit |
Maximum Load |
power quantity |
Maximum load below which it may not be increased |
Minimum Load |
power quantity |
Minimum load below which it may not be reduced. |
Power Ramp Rate |
Power Quantity (rate), Duration, Begin Quantity, End Quantity |
Between the Begin Quantity and End Quantity, Power can ramp at Quantity per Duration |
Drop Ramp Rate |
powerRampRate |
Maximum rate that load can be reduced. Begin Power must be greater than End Power |
Raise Ramp Rate |
powerRampRate |
Maximum rate that load may be restored |
Is Controllable |
Bool |
Resource can be direct controlled. Warrant must be in envelope |
Resource Class |
Enumerated string |
While a diverse set or resources can reduce risk, some resources may present covariant risk. For example, solar power in a region may ebb and flow in synchrony. |
In addition, voltage regulation services have their own semantics to specify voltvar.
Table 7‑2 Semantics for Voltage Regulation Services
Name |
Definition |
Note |
VMin |
varQuantity |
VMin is the IEEE 1547 minimum voltage level of 88% of nominal voltage where the PV inverter must disconnect |
VMax |
varQuantity |
VMax is the IEEE 1547 maximum voltage level of 110% of nominal voltage where the PV inverter must disconnect. |
QMax |
varQuantity |
Qmax is the inverter’s current var capability and may be positive (capacitive) or negative (inductive). It would be the VA capability left after supporting the W demand. |
voltVar |
voltageQuanity & varQuantity |
|
Resource Capability Products describe the capabilities of the resource using the semantics as above. The simpler of these interfaces mimic those found in traditional markets. Offer Load and Offer Generation describe more complete and abstract interfaces.
Table 7‑3 Responsive Load Resource – Simple Form
Name |
Definition |
Note |
Mrid |
mrid |
|
Base Load |
powerQuantity |
Load of system before request |
Drop Ramp Rate |
rampDown |
Ramp rates are sorted by Descending maxima. |
Minimum Load |
powerQuantity |
Load of system under full response |
Raise Ramp Rate |
rampUp |
Ramp rates are sorted by ascending maxima. |
The resource load is a simplified version of the market interface that appears in the TC57 CIM. Note that some of the terms are different because EMIX unifies terms across interfaces..
Table 7‑4 Offer Load Reduction
Name |
Definition |
Note |
Mrid |
Mrid |
|
Drop Ramp Rate |
dropRampRate, multipleoccurs |
Ramp rates are sorted by descending maxima to assess response. |
Min Load |
powerQuantity |
Minimum Load system will accept |
Min Load Reduction |
powerQuantity |
Minimum reduction request resource will accept |
Min Load Reduction Cost |
Price |
Minimum price to get resource to make minimal response |
Min Load Reduction Interval |
Duration |
Minimum time for which resource will accept a load reduction |
Min Time Bet Load Red |
Duration |
Shortest time that load must be left at normal levels before a new load reduction. |
Raise Ramp Rate |
raiseRampRate |
Ramp rates are sorted by ascending maxima to assess recovery. |
Shutdown Cost |
Price |
Fixed cost associated with committing a load reduction |
Generation resources are very similar to load resources. As to grid effect, adding 10 MW of generation and gaining 10 MW less of load are similar.
Table 7‑5 Registered Generation Capabilities
Name |
Definition |
Note |
Mrid |
mrid |
|
Lower Ramp Rate |
dropRampRate |
Regulation down response rate in power units / minute |
Maximum Operating Power |
maxOperatingPower |
Resource cannot be requested to operate at higher than maximum operating power |
Minimum Operating Power |
minOperatingPower |
Resource cannot be requested to operate at lower than minimum operating power |
Raise Ramp Rate |
raiseRampRate |
Apply ramp rates consecutively to find power capabilities. |
Spin Reserve Ramp |
powerRampRate |
|
The Power Offer is the most complete and generic description of a power resource, including perfoamcne and economic requirements.
Table 7‑6 Power Offer Capabilities
Name |
Definition |
Note |
Mrid |
mrid |
|
Startup Cost |
Price |
Cost to initiate any resource |
Minimum Resource Cost |
Price |
Minimum cost to elicit response from Resource |
Raise Ramp Rate |
raiseRampRate |
Apply ramp rates consecutively to find power capabilities. |
Maximum Power |
maxOperatingPower |
Resource cannot be requested to operate at higher than maximum operating power |
Minimum Operating Power |
minOperatingPower |
Resource cannot be requested to operate at lower than minimum operating power |
Lower Ramp Rate |
dropRampRate |
Apply ramp rates consecutively to find power capabilities. |
Offer Segment |
offerSegment |
Economic requirements for incremental power, sorted by maximum power rate ascending. |
Ancillary Services Products are typically products provided by a Resource Capability and used by a system operator to stand by to deliver changes in power to balance the grid on very short notice. Ancillary services include Regulation Up, Regulation Down, Spinning Reserve, and Non-Spinning Reserve. Ancillary services are different from other power and energy services in that they must be paid for availability, whether or not they perform. Of course, they must also perform when called. The ancillary services products described below are typical of ancillary service products defined by and procured by US ISO/RTO markets.
Ancillary Services descriptions are applied to a WS-Calendar Sequence to create the EMIX Terms used for exchange with other parties
Regulation services are used to maintain accumulated frequency error within allowable bounds.
Table 8‑1 Power Regulation Product Description
Name |
Definition (Normative) |
Note (Non-Normative) |
Product Type |
String, enumerated |
Regulation Down |
Availability Period |
ws-calendar interval |
Interval during which the resource is warranted to be ready to perform. |
Autonomous Dispatch |
Bool |
If true, service notes local conditions and dispatches itself. If false, it waits for dispatch request from Operator. |
Delivery Rate Units |
Typically kW or MW. |
Unit is normally kilowatt-hours (kW) or megawatt-hours (MW) |
Dispatch Up |
Integer seconds |
Time in which resource can respond to a request to increase energy provided. If zero, no dispatchUp available. Can also be startup delay for non-spinning reserve. |
Dispatch Down |
Integer seconds |
Time in which resource can respond to a request to decrease energy provided. If zero, no dispatchDown available |
voltage |
Integer |
Expressed in KV |
hertz |
Integer |
|
Ac/dc |
AC or DC |
|
Ancillary Services are used for short term balancing of supply and demand by a system operator.
Table 8‑2 Reserves Product Description
Name |
Definition (Normative) |
Note (Non-Normative) |
Product Type |
String, enumerated |
Regulation Down |
Availability Period |
vcalendar |
Interval during which the resource is warranted to be ready to perform |
Maximum Delivery Rate |
Integer |
In home contracts this is limited by service size |
Minimum Delivery Rate |
Integer. |
Determines minimum charges during period |
Delivery Rate Units |
Typically kWh or MWh. |
Unit is normally kilowatt-hours (kWh) or megawatt-hours (MWh) |
Maximum Delivery Time |
Duration |
When called on, for how long can this asest deliver |
Cycle Time |
Duration |
When called on, how long until this asset can be called on again. |
Higher quality power can obtain a market premium. A buyer willing to accept lower quality power may be able to obtain inexpensive power. Power Qualities must be measurable, discrete, and on a spectrum allowing the buyers to make choices. They must also be verifiable, measurable by defined protocols, so performance can be compared to promise.
Table 9‑1: AC Power Quality
Name |
Definition |
Type |
Note |
Measurement Protocol |
A string containing an identification of the standard or other protocol used to measure power quality |
String |
Text string with formal number of the standard used, e.g., “EN 50160”, “IEEE 1549-2009” |
Power Frequency |
A floating point number describing the nominal Power frequency |
Float |
Measured rather than nominal value, e.g. 50.4, 59.9. 0 for DC |
Supply Voltage Variations |
An unsigned integer count of Supply Voltage Variations during the period |
Float |
See referenced standards for definition, measurement protocol and period. E.g., 7 in the billing period. |
Rapid Voltage Changes |
An unsigned integer count of Rapid Voltage Change events during the period |
Ulong |
See referenced standards for definition, measurement protocol and period. E.g., 0 in the billing period. |
Flicker |
An unsigned integer count of Flicker events during the period |
Ulong |
See referenced standards for definition, measurement protocol and period. E.g., 0 in the billing period. |
Supply Voltage Dips |
An unsigned integer count of Supply Voltage Dip events during the period |
Ulong |
See referenced standards for definition, measurement protocol and period. E.g., 0 in the billing period. |
Short Interruptions |
An unsigned integer count of Short Interruption events during the period |
Ulong |
See referenced standards for definition, measurement protocol and period. E.g., 0 in the billing period. |
Long Interruptions |
An unsigned integer count of Long Interruption events during the period |
Ulong |
See referenced standards for definition, measurement protocol and period. E.g., 0 in the billing period. |
Temp Overvoltage |
An unsigned integer count of Temporary Overvoltage events during the period |
Ulong |
See referenced standards for definition, measurement protocol and period. |
Supply Voltage Imbalance |
An unsigned integer count of Supply Voltage Imbalance events during the period. Optional, and not meaningful for DC. |
Ulong |
See referenced standards for definition, measurement protocol and period. |
Harmonic Voltage |
A floating point number for the Harmonic Voltage during the period. For DC, distortion is with respect to a signal of 0 Hz |
Float |
See referenced standards for definition, measurement protocol and period. The period is usually much shorter than other power quality measures. |
Mains Voltage |
A floating point number Mains [Signaling] Voltage |
Float |
Nominal value, e.g, 110, 130, 220, 208. See referenced standards for definition and protocol. |
Transport costs affect the delivery of energy in all markets. Today’s electrical power markets use different terms in transmission and delivery, but the underlying elements are the same. Like the other products, aspects of transport charges may change over time, and so can be expressed as EMIX Terms by applying the Transport Description to the WS-Calendar Sequence.
Table 10‑1: Transport Description
Name |
Definition (Normative) |
Note (Non-Normative) |
Point of Receipt |
Transaction Node |
Where power enters a network or changes ownership |
Point of Delivery |
Transaction Node |
Where power exits a network or changes ownership |
Transport Access Fee |
Price |
Fixed Charge (not dependent on congestion) to access transport system |
Transport Congestion Fee |
Price. |
Congestion fee per unit of energy for energy flowing from receipt to delivery point. Can be a positive or negative price. e. |
Transport Congestion Fee Units |
Energy Units |
|
Marginal Loss Fee |
Price |
Marginal Loss Fee |
Marginal Loss Fee Units |
Energy Units |
|
Transport Loss Factor |
Float |
Reduction in amount delivered due to loss during transport. (Loss Factor * purchase amount) = delivered amount |
Conversion Loss Factor |
Float |
Reduction in amount delivered as product voltage is changed or as converted from AC to DC or DC to AC. (Loss Factor * purchase amount) = delivered amount |
currency |
From CEFACT. Optional |
Usually inherited, but allowed to permit stand-alone artifact |
There MAY be multiple instances of the above Artifacts in a single Price instance.
Warrants are specific assertions about the extrinsic characteristics of power that may affect market pricing. Warrants are in effect Product artifacts as defined in EMIX. Warrants start as Product Descriptions that are applied to the intervals in a sequence and to the gluon. There may be zero intervals in a product if the unchanged product description applies to all. The intervals in a warrant may differ from those of the product on the outside of the envelope.
Sometime warrants are only applicable within certain jurisdictions. For example, in today’s energy markers (2010) energy warranted as renewable in the Pacific Northwest can include Hydro power. Energy markets in California exclude Hydro Power from their definition of Renewables. The means credits or mandates for renewable energy in California, are not met by Products warranted as Renewable in the Northwest.
Some warrants may be separable from the underlying energy. For example a warrant that a source of energy is generated by a source that is certified as "green" by an authority, may be issued a "green certificate". Such a certificate can be separately traded, so the Warrant information for a product should specify if the "green certificate" is (1) accompanying the energy, (2) sold to a third party, or (3) the source is not green but a green certificate has been purchased and accompanies the energy.
Warrant Element |
Definition |
Note |
Product Quality |
A Product-specific assertion of Quality |
If during an offer, can be a promise of quality. If during verification, and be actual measurements. If during an indication of interest, might be a minimum standard. |
Warrant Environmental |
Quantifies the environmental burden created during the generation of the electric power. |
These are as identified as per the artifact environmental.rdf |
Warrant Content |
The proportion of the product defined that is from non-fossil fuel sources, including but not limited to “hydroelectric”, “solar”, and “wind”. |
The nature of the original input to storage is not altered when drawn from storage. |
Warrant Source |
Individual source warrants |
In aggregate may be the same as a warrantContent |
Warrant Controllability |
Assertion that a resource referenced on the face of the envelope can be controlled and/or operated by or to some standard. |
For example, some ISOs will accept a resource as direct load controllable if so asserted by a third party aggregator. |
If the first interval in a series has a price only, all Intervals in the Sequence have a price only and there is no price in the Product
If the first interval in a series has a quantity only, all Intervals in the Sequence have a quantity only and there is no quantity in the Product
If the first interval in a series has a price & quantity, all Intervals in the Sequence MUST have a Price and Quantity and there is neither Price not Quantity in the Product
All intervals in a sequence may be restricted to single service location. What are the rules?
The following individuals have participated in the creation of this specification and are gratefully acknowledged:
Participants:
Bruce Bartell, Southern California Edison
Timothy Bennett, Drummond Group Inc.
Edward Cazalet, Individual
Toby Considine, University of North Carolina at Chapel Hill*
William Cox, Individual
Sean Crimmins, California Independent System Operator
Phil Davis, Schneider Electric
Sharon Dinges, Trane
Pim van der Eijk, Sonnenglanz Consulting
Girish Ghatikar, Lawrence Berkeley National Laboratory
Todd Graves, Microsoft Corporation
Anne Hendry, Individual
David Holmberg, NIST*
Gale Horst, Electric Power Research Institute (EPRI)
Ali Ipakchi, Open Access Technology International Inc. (OATi)
Perry Krol, TIBCO Software Inc.
Derek Lasalle, JPMorganChase
Jeremy Laundergren, Southern California Edison
Alex Levinson, Lockheed Martin*
Dirk Mahling, CPower
Scott Neumann, Utility Integration Solutions Inc.
Robert Old, Siemens AG
John Petze, Individual
Donna Pratt, ISO/RTO Council
Ruchi Rajasekhar, Midwest Independent Transmission System Operator, Inc.
Carl Reed, Open Geospatial Consortium, Inc. (OGC)*
Jeremy Roberts, LonMark International*
Anno Scholten, Individual
Pornsak Songkakul, Siemens AG
Bill Stocker, ISI/RTO Council (IRC)
David Sun, Alstom Power Inc.
Jake Thompson, EnerNOC
Matt Wakefield, Electric Power Research Institute (EPRI)
David Webber, Individual
Leighton Wolffe, Individual
Brian Zink, New York Independent System Operator (NYISO)
Some markets, known as ancillary services, can offer substantially more for the same load than does the traditional market. Suitability of an offering for these diverse markets is determined by aspects of the response such as how fast the Product can offer the power, how long it can offer the power, how frequently the Product can offer the power, etc. Higher prices come with higher risks; the costs of non-performance in ancillary markets can be substantially higher as well.
Ancillary services require detailed interval metering. For the regulation product, 4 to 6 second interval metering and direct control of the generator is today required by the balancing system operator. However, there are current initiatives by FERC and many ISOs to allow loads and storage to provide ancillary services. One of the potential applications of the metering and communications infrastructure of the smart grid is to facilitate the participation of loads and distributed energy Products such as storage in providing balancing / ancillary services to the grid.
There is general agreement across North America on the names of ancillary services. There is general agreement on the performance profile for each ancillary service as well. There are minor differences in some of the actual performance profiles from region to region. Periodically, the performance requirements are changed for named services.
Ancillary service performance can be characterized as “meet or exceed” requirements. A given service level may meet the requirements for more than one named service. A power product that can be sold in more than one market has more potential value to the seller. Transparent service and performance requirements associated with market prices are likely to encourage sellers to make minor upgrades when they can thereby reach new markets.
For these reasons, we opted not to name the ancillary services in the standard, but instead to exchange the actual performance requirements either offered or required.
For reference, here are some common performance requirements in use today. These are non-normative. They are include here to assist the practitioner in thinking about ancillary services as a deliverable.
Regulation
Spinning Reserve
Non-Spinning Reserve
Each type of Electrical Power and Energy product has its own definitions and its own descriptive parameters. These artifacts are the specific descriptions relevant to defining the potential utility of the power and energy product. The Power and Energy Artifacts describe the intrinsic information. There may be cases when an Artifact is held in the envelop contents, perhaps as supporting information supporting the intrinsic prices.
To put the terms “Power” and “Energy” into the proper context for this specification, the following definitions will be used:
Generically, the use of the term “Power” refers to “Real Power” and is expressed in Watts. Otherwise, one talks of Apparent Power or Complex Power in VA, or Reactive Power in VARs.
In the context of this specification, the price of Power and Energy will be expressed in the same unit, $/MWh. The argument for this comes from [Stoft, p. 32]. The use of Power is as a flow, and its total cost is measured in unit currency (i.e., dollars) per hour, not just unit currency. The price per unit cost of Power is measured in unit currency per hour per megawatt (MW) of Power flow, or unit currency/MWh. In the same manner, the total cost of a certain quantity of Energy is measured in unit currency. The price per unit cost of energy is measured in unit currency/MWh, which is the same as for Power.
To clear up confusion on units for pricing, refer to definitions on pp. 30-33 in [Stoft].
Revision |
Date |
Editor |
Changes Made |
WD01 |
2009-12-08 |
Toby Considine |
Initial Draft from templates and outline |
WD02 |
2010-01-12 |
William Cox |
Inserted information model details from TC discussions |
WD03 |
2010-03-10 |
William Cox |
Change to envelope and certificate metaphor. Changes in mandatory and optional definitions. |
WD04 |
2010-03-24 |
William Cox |
Updates based on TC comments and corrections. Additional open issues in TC agenda. |
WD05 |
2010-05-18 |
Toby Considine |
Aligned elements with current draft if WS-Calendar, cleaned up some language to align with the last two months of conversation. Extended envelop and intrinsic/extrinsic language |
WD06 |
2010-05-21 |
Toby Considine |
Began incorporating TeMIX language. Changed Certificates to Warrants. Fleshed out Energy Artifacts |
WD07 |
2010-07-07 |
Toby Considine |
Incorporated Aaron Snyder’s extensive re-write into Power & Energy section |
WD08 |
2010-08-10 |
Toby Considine |
Extensive re-write for narrative quality, responded to first 52 comments, Updated to include WS-Calendar WD08 language, added tables of table, examples |
WD09 |
2010-08-18 |
Toby Considine |
Incorporated recent WS-Calendar changes to update Products. Added explanation of WS-Calendar. Cleaned up double entry of Partitions. |
WD10 |
2010-08-30 |
Toby Considine |
Reduced argumentation in intro, excluded WS-Calendar re-writes, pointed to WS-Calendar appendices. Merged AC and DC |
WD11 |
2010-09-05 |
Toby Considine |
Distinguished between Intrinsic elements and Generic Product, incorporated inheritance language into GP, Re-created T&D as a much smaller Transport Artifact, changed envelope language to face and contents. |
WD12 |
2010-10-26 |
Toby Considine |
Responded to many Jira comments. Re-created T&D as a much smaller Transport Artifact, changed envelope language to face and contents. Responded to many Jira comments. Descriptions now based on WD12 Schema. |
WD13 |
2010-11-01 |
Toby Considine |
Removed repetitive discussion of WS-Calendar objects. Reflect new use of WS-Calendar Sequence in Schema. Recast Options to describe reserves. |
WD14 |
2010-11-09 |
Toby Considine |
Changes to resources, block power, misc. tightening of document |
WD15 |
2010-11-14 |
Toby Considine |
EMIX Sequence changed to EMIX Terms. General tightening. Addition of Load and Power Offers, including 3-part bids for each. |
CD01 |
2010-11-15 |
Toby Considine |
Minor changes as per comments |
[1] http://wordnet.princeton.edu/
[2] Ibid
[3] The phrase “prices to devices” is used in energy policy discussions to describe a market model in which energy use decisions are distributed to each device that uses energy. Under this model, decisions about whether to use energy now or delay energy use until later are best made where the value is received for that energy use, the end device. The smart toaster is shorthand for the smallest, least capable device that can receive such a message.
[4] Ibid