This specification defines an
information model to exchange Price and Product information 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. It is anticipated to be used for information exchange in a
variety of market-oriented interactions.
The EMIX Technical Committee (TC) is developing this
specification in support of the US Department of Commerce National Institute of
Standards and Technology (NIST) Framework and Roadmap for Smart Grid
Interoperability Standards [NIST Roadmap] and in support of the US
Department of Energy (DOE) as described in the Energy Independence and Security
Act of 2007 (EISA 2007) [EISA].
Key to reading this 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 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].
1.2 Process
This information model 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” [NIST 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 TC57]. 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).
Both the supply and the use of energy, and therefore the
market value, are time dependent, so precise communication of time of delivery
is a significant component of product definition. EMIX incorporates schedule
and interval communication interfaces from Web Services Calendar ([WS-Calendar])
to communicate schedule-related information. Practitioners should read the [WS-Calendar]
specification or the [WS-Calendar Note].
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.
1.3 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.
ISO42173 United Nations Centre for Trade Facilitation and Electronic
Business, Currency codes, ISO 42173A - Code List
Schema Module http://www.unece.org/uncefact/codelist/standard/ISO_ISO3AlphaCurrencyCode_20100407.xsd
GML L van den Brink, C Portele, P.
Vretanos Geography Markup Language (GML) simple features profile,
OpenGIS® Implementation Standard, GML 3.2 Profile, Version 2.0, October 2010, http://schemas.opengis.net/gml/3.2.1/gml.xsd
SI Units Bureau International des Poids et
Mesures (BIPM), The International System of Units, 8th Edition, May
2006. http://www.bipm.org/en/si/si_brochure/general.html
SOA-RM OASIS Standard, OASIS Reference
Model for Service Oriented Architecture 1.0, October 2006 http://docs.oasis-open.org/soa-rm/v1.0/
URI T. Berners-Lee, R.
Fielding, L. Masinter, Uniform Resource Identifier (URI): Generic Syntax,
http://www.ietf.org/rfc/rfc3986.txt, January 2005
WS-Calendar OASIS Committee
Specification 1.0, WS-Calendar, July 2011, http://docs.oasis-open.org/ws-calendar/ws-calendar-spec/v1.0/cs01/ws-calendar-spec-v1.0-cs01.pdf
XML Schema H. Thompson, D Beech, M Maloney, N Mendelsohn, XML
Schema Part 1: Structures Second Edition, http://www.w3.org/TR/xmlschema-1/ October 2004
PV Biron, A Malhotra, XML Schema Part 2: Datatypes Second Edition, http://www.w3.org/TR/xmlschema-2/ October 2004.
1.4 Non-Normative References
Budeanu C.I. Budeanu, The different
options and conceptions regarding active power in nonsinusoidal systems.
Rumanian National Institute, 1927
Caramia P Caramia, G. Carpinelli, P Verde, Power
Quality Indices in Liberalized Markets, Wiley 2009
EISA Energy Independence and Security
Act (EISA 2007) http://www.gpo.gov/fdsys/pkg/PLAW-110publ140/content-detail.html
EN50160 EN50160-2000 (2003) Electromagnetic
Compatibility (EMC) – Part 4-30: Testing and Measurement Techniques – Power
Quality Measurement Methods, Edition 2, June.
FIX Financial
Information eXchange (FIX) Protocol, http://www.fixprotocol.org/specifications/FIX.5.0SP2
IEC TC57 IEC TC 57 Power Systems Management
and Associated Information Exchange, IEC 61968-9 Application integration at
electric utilities - System interfaces for distribution management - Part 9:
Interfaces for meter reading and control http://webstore.iec.ch/preview/info_iec61968-9%7Bed1.0%7Den.pdf
IEC 61970-301, Energy management system application program interface (EMS-API)
- Part 301: Common information model (CIM) base http://webstore.iec.ch/Webstore/webstore.nsf/Artnum_PK/42807
IEC61000-4-30 IEC 61000-4-30–2003, Electromagnetic
compatibility (EMC) – Part 4-30: Testing and measurement techniques – Power
quality measurement methods
IEEE1519 IEEE1159-2009, IEEE Recommended
Practice for Monitoring Electric Power Quality, ieee.org
IEEE1547 IEEE 1547, Standard
for Interconnecting Distributed Resources with Electric Power Systems, ieee.org
IEEEv15#3 Pretorius, van Wyk, Swart. An
Evaluation of Some Alternative Methods of Power Resolution in a Large
Industrial Plant, 1990 IEEE Transactions on Power Delivery, VOL. 15, NO. 3,
JULY 2000.
ISO 20022 ISO Standards, Financial Services -
Universal financial industry message scheme, http://www.iso20022.org/UNIFI_ISO20022_standard.page
Kingham Brian Kingham, Quality of
Supply Standards: Is EN 50160 the Answer?, 17th Conference of
Electrical Power Supply Industry, Macau, 2008; also EPRI Power Quality
Conference, 2008; Also available at
http://www.oasis-open.org/committees/download.php/37248/Power%20Quality%20White%20Paper%20from%20Schneider.pdf
NAESB PAP03 Requirements Specification for Common
Electricity Product and Pricing Definition, North American Energy Standards
Board [NAESB], March, 2010 NAESB Wholesale Electrical Quadrant Business
Practice http://www.naesb.org/member_login_check.asp?doc=fa_2010_weq_api_6_a_ii.doc
NAESB Retail Electrical Quadrant Business Practice, http://www.naesb.org/member_login_check.asp?doc=fa_2010_retail_api_9_a.doc
NAESB MDL Wholesale Electrical Quadrant Business
Practice Master Data Element List, http://www.naesb.org/member_login_check.asp?doc=fa_2010_weq_api_6_a-c.doc
Retail Electrical Quadrant Business Practice Master Data Element List, http://www.naesb.org/member_login_check.asp?doc=fa_2010_retail_api_9_a-c.doc
NAESB PAP10 NAESB Wholesale Electrical Quadrant
Business Practice Standard PAP10 http://www.naesb.org/member_login_check.asp?doc=fa_weq_2010_ap_6d.doc
NAESB Retail Electrical Quadrant Business Practice Standard PAP10
http://www.naesb.org/member_login_check.asp?doc=fa_req_2010_retail_ap_9d.doc
Energy Usage Model (freely available): http://www.naesb.org/pdf4/naesb_energy_usage_information_model.pdf
NAESB M&V Measurement and Verification
Standards
Wholesale Electrical Quadrant Business Practice Standard: http://www.naesb.org/member_login_check.asp?doc=fa_2010_weq_api_4a_4b.doc
Retail Electrical Quadrant Business Practice Standard:
http://www.naesb.org/member_login_check.asp?doc=fa_2010_retail_api_3_c.doc
NIEM NIEM Technical Architecture
Committee (NTAC), National Information Exchange Model Naming and Design
Rules v1.3, October 2008, http://www.niem.gov/pdf/NIEM-NDR-1-3.pdf
OpenADR Mary Ann Piette,
Girish Ghatikar, Sila Kiliccote, Ed Koch, Dan Hennage, Peter Palensky, and
Charles McParland. 2009. Open Automated Demand Response Communications
Specification (Version 1.0). California Energy Commission, PIER Program.
CEC-500-2009-063. http://openadr.lbl.gov/pdf/cec-500-2009-063.pdf
TeMIX Transactive Energy Market
Information Exchange [TeMIX] an approved Note of the EMIX TC. Ed Cazalet et al.
http://www.oasis-open.org/committees/download.php/37954/TeMIX-20100523.pdf
NIST Roadmap NIST Framework and Roadmap for Smart
Grid Interoperability Standards, Release 1.0, http://www.nist.gov/public_affairs/releases/upload/smartgrid_interoperability_final.pdf
NIST PAP03 Details of PAP03 can be found at http://collaborate.nist.gov/twiki-sggrid/bin/view/SmartGrid/PAP03PriceProduct
RFC5545 B. Desruisseaux Internet Calendaring
and Scheduling Core Object Specification (iCalendar), http://www.ietf.org/rfc/rfc5545.txt, IETF RFC 5545, September 2009.
RDDL J Borden, T Bray, Resource
Directory Description Language (RDDL) Version 2.0, October, 2002, http://www.rddl.org/RDDL2
UML Unified Modeling
Language (UML), Version 2.2, Object Management Group, February, 2009, http://www.omg.org/spec/UML/2.2/
WS-Calendar Note OASIS Committee Note Public Review Draft,
WS-Calendar Conceptual Overview, http://docs.oasis-open.org/ws-calendar/ws-calendar/v1.0/CD01/WS-Calendar-Conceptual-Overview-CD01.pdf
1.5 Namespace
XML namespaces and prefixes used in this specification are
shown in Table 1‑1.
Table 1‑1: XML Namespaces in this standard
All OASIS Schemas are permanently accessible through
directory structures that include major and minor version numbers. They are
also accessible through RDDL files that describe these structures and version
in directories below http://docs.oasis-open.org/emix/emix.
The schema document at that URI may however change in the
future, in order to remain compatible with the latest version of EMIX
Specification. In other words, if the schemas namespaces change, the version of
this document at http://docs.oasis-open.org/ns/emix/2011/
will change accordingly.
In
keeping with OASIS standard policy, a RDDL document locating the schemas
defined in this specification will persist in http://docs.oasis-open.org/ns/emix.
The EMIX schema versioning policy is that namespaces reflect
the year and month in which they were released. For this version, this rule
results namespaces as indicated in the first four namespaces listed in Table 1‑1.
Namespace maintenance as described above also
addresses the need for schema versioning; such information is already contained
in the directory structures found at http://docs.oasis-open.org/emix/emix/.
Versioning beyond that which is required by the namespace maintenance policy is
not specified.
1.6 Naming
Conventions
The names of EMIX XSD Elements and Attributes follow Lower
Camel Case convention.
Example:
<element
name="componentService"
type="emix:ComponentServiceType"/>
The names of EMIX Types follow Upper Camel Case convention
and Type names are postfixed with “Type“.
Example:
<complexType
name="ComponentServiceType">
1.7
Editing Conventions
For readability, Element names in tables appear as separate
words. In the Schemas, they follow the rules as described in Section 1.6.
Terms defined in this specification or used from specific
cited references are capitalized; the same term not capitalized has its normal
English meaning.
All sections explicitly noted as examples are informational
and SHALL NOT be considered normative.
All UML and figures are illustrative and SHALL NOT be
considered normative.
1.8 Security
Approaches
EMIX will normally be conveyed in messages as part of
business processes. Each business process will have its own security needs,
including different consequences for failure of security. EMIX relies on the
business processes using the standard to ensure secure exchange of Price and
Product information in energy market transactions.
Energy markets have been characterized by tariffs and
embedded knowledge that makes decision automation difficult. Different market
segments use conflicting terms for similar attributes. Smart grids introduce
rapidly changing products and product availability, with associated dynamic
prices. A lack of a widely understood model conveying market information has
been a barrier to development and deployment of technology to respond to
changing market conditions.
Price and Product Descriptions are actionable
information. When presented with standard messages conveying price and
product information, 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 not strictly economic
processes. These tariffs convey the price and product information to make
buying and selling decisions easier. The same information can be derived from
market operations in non-tariffed markets. EMIX defines an information model to
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, may not have the same value 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, transactions, and delivery.
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.
This specification uses a definition of Product that is inclusive
of attributes including schedule, location, and source. Some markets define
products in a more restricted or general manner. We combine the various
attributes of a thing bought or sold, shown graphically in FIGURE 2-1. In this
specification we define a product to include both the type of product (e.g.,
Energy), the response time (e.g. fast enough to qualify as Regulation), and the
delivery time as shown by the black arrow. Others (e.g., ISO Wholesale markets)
define products at a higher level (e.g. Energy) which is considered the same
product regardless of delivery time, as indicated by the gray arrow.
Figure 2‑1is illustrative, not normative; the order of
significance is not defined in this specification. Moreover, there are
attributes such as Source or Power Quality that do not easily fit in a single
dimension—and a renewable source typically makes a different Product with
different value.
Fortunately, this is often a distinction without moment, as
the information needed for a transaction involves the more detailed
characteristics as indicated by the black arrow, and the specific definition of
a Product is part of the Market Context.
Figure 2‑1: Attributes of a Product
2.2
Approach
The approach of the TC strives to support price and product
communication among current operating models of wholesale market operators,
utilities, exchanges, Demand Response providers, bilateral markets, and open
retail and wholesale markets as well as new market models that may evolve.
Markets use a range of terminology. For interoperation, EMIX
uses the terminology of market "transactions" and "tenders"
to characterize the communication of price and product across markets. Some
markets may call a transaction an "award" or a "contract".
Some markets may call a tender a "bid", "offer" or
"rate". EMIX uses the transaction and tender terminology that can be
translated to the terminology of various markets.
System Operator Markets such as those operated by
Independent System Operators (ISO) and Regional Transmission Operators (RTO)
use specific information models for communication of resource offers (tenders)
for Energy and Ancillary Services products. Retail service providers use
specialized terminology to characterize retail full requirements and other
tariffs. Bilateral wholesale markets and exchanges may use a
"bid/ask" terminology and various contract types. Each of the markets
may use specialized market clearing methods or the price may be the result of a
cost-based tariff calculation. Market mechanisms and tariff calculations are
out of scope for EMIX.
The EMIX information model is intended to support
interoperation among markets that may use different information models.
Power is a commodity good 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. EMIX assumes this
product differentiation and defines multiple products based on the underlying
good.
Throughout this work, the specification refers to the intrinsic
and extrinsic properties of an energy product. An intrinsic property is one “belonging
to a thing by its very nature.” An extrinsic property is one “not
forming an essential part of a thing or arising or originating from the
outside.” In EMIX, the term intrinsic properties refers to those that can
be measured and / or verified at the point of delivery, such as 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 Artifacts can communicate both intrinsic and extrinsic
properties. EMIX is designed to support arrange of
markets from those in which extrinsic properties must clear just as do
intrinsic properties, to markets may not be concerned with the extrinsic
properties.
EMIX is an information model that assumes conveyance within
a service-based environment, as defined in the OASIS Reference Model for
Service Oriented Architecture 1.0 [SOA-RM].
Time semantics are critical to EMIX. Consider two sellers
that offer the same product. For the first, one must start planning an hour or
more in advance. The second may be able to deliver the product within five
minutes of a request. The service start time is the time when product delivery
begins. Because this service start time and service period are all that matters
to product delivery, different providers using quite different technologies can
provide equivalent product as specified in EMIX if each is given adequate
notice. For other products, timeliness of notice is of the essence, and the
first may not be able to provide the service.
EMIX uses semantics from [WS-Calendar] to describe
Time, Duration, and Schedule. An overview of [WS-Calendar] semantics is
provided in Appendix E.
As a conceptual aid, consider 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 of the envelope is
meant for high-speed automated processing. The simplest devices, including the
proverbial smart toaster, may understand only the intrinsic qualities. 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
immediately or delay energy use until a later time are best made where the
value is received for that energy use, that is, at the end device. The smart
toaster is shorthand for the smallest, least capable end device that can
receive such a message. It is anticipated 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 support the price for the intrinsic qualities on the face of the
envelope. These extrinsic qualities are separable from the intrinsic
transaction and perhaps can be traded in secondary markets. The contents can
include Warrants about the source and the environmental attributes which
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.
The extrinsic information within the envelope may contain
information that supports the price among the Extrinsic information conveyed
within the envelope. 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.
2.5 Tenders and Transactions for Power Products and Resource
Capabilities
The focus of EMIX is on a Price and Product information
model for 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.
EMIX is intended for commercial transactions in all types of
markets including ISO/RTO markets, exchange markets, regulated markets,
regulated retail tariffs, open markets, and wholesale and retail bilateral
markets. (ISO refers to Independent System Operators. ISOs provide
non-discriminatory access to transmission, operate spot markets and maintain
grid reliability. RTO refers to Regional Transmission Organizations. RTOs
perform the ISO functions on a regional basis.) The commercial practices
that determine prices vary in these markets but all markets can benefit from
interoperable communication of Price and Product information.
Transactions in most markets begin with tenders (offers to
buy or sell) by one 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 4, “Envelopes: EMIX Base and its Derivatives” describes EMIX
Base Type, the core of EMIX information models.
In many electricity markets, Operators are offered
electrical products based on specific resources such as 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.
2.6 Transport
Product transport from a point of injection to a grid to a
point of takeout to a grid is also described by the EMIX information model.
Product transport can be characterized by (1) the quantity transported and
price, or (2) the quantity transported and cost detail.
Transport 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 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 services
are discussed in Section 11, “Power Transport Product Description”.
2.7
Verification of Response
Many products, e.g. those transacted for Demand Response,
have detailed verification methods. In today’s markets, verification can be
quite complex.
Verification is out of scope for this specification.
Measurement and Verification is fully specified by NAESB Business Practices for
Measurement and Verification [NAESB M&V]. This specification does
not define verification.
3 Guide
to the Schema Structures
The EMIX 1.0 Specification consists of four schemas:
- The EMIX
schema defines the framework and extensibility as well as agreement types
common to many markets. The EMIX schema consists of three files—emix.xsd, emix-terms.xsd, and emix-warrants.xsd
- The SI
Scale schema, defines a code list enumerating the characters indicating
the decadic scale for measurements defined by the System International
(SI).
- The Power
schema defines the specific information exchanges, based on the EMIX
framework, needed for markets in power and energy. The Power schema consists of three files—power.xsd, power-product.xsd,
and power-quality.xsd.
- The
Resource schema describes specific capabilities of devices and systems,
irrespective of the underlying technologies that affect power and energy
markets.
Note that
EMIX and Power schemas are broken into multiple files for convenience of human
readers and editors.
The Power and Resource schemas are, in effect, the first
extensions to the EMIX Schema. The Power schema extends the EMIX schema to
define products for Power markets. The Resource schema extends the Power schema
to provide information on the capabilities and the responsiveness of devices
and systems in support of decisions regarding tenders and transactions for
products that can be provided by or consumed by Resources.
3.1 Use of Core Type Extension to define EMIX
The core elements of EMIX are abstract types. The concrete
types used in exchangeable information models are built by extending those
abstract types to create the information exchanges for energy markets. Product
Descriptions are built out of lower-level Items. Schedules are populated with
Product Descriptions. Top level models, derived from EMIX Base, incorporate
Schedules. Top level models can be exchanged at an Interface between systems or
owners.
The abstract EMIX Base Type defines a Product Description
conveyed by a Schedule. That Schedule may be as simple as a single 5 minute
interval on a particular day, or as complex and repeating as you can find in
your own personal calendar. Any type derived from the EMIX Base Type contains a
Sequence that can contain any Product Description. Information elements derived
from the EMIX Base include Products, Options, TeMIX, and Delivery (Metered
Information). The definitions in Table 3‑1 assume that the reader is familiar
with terms defined in [WS-Calendar]; as a
convenience to the reader, these are summarized in section 3.2.
Table 3‑1: EMIX Core Abstract Types
|
Type
|
Description
|
|
Item
Base
|
Abstract base type for units for EMIX
Products. Item Base does not include Quantity or Price, because a single
Product may have multiple quantities or prices associated with each Interval.
|
|
Schedule
|
EMIX Products are delivered for a Duration, at a
particular time. EMIX relies on the Interval and the Gluon as defined in [WS-Calendar]
to communicate Schedules. The Schedule names a collection, but is not itself
a type.
|
|
Product
Description
|
Product Description is derived from an abstract Artifact
type that resides within [WS-Calendar] Components, and all Product
Description-derived types can therefore reside within those Components as
well. The Product Description is placed in Components of the Schedule.
|
|
EMIX
Base
|
The EMIX Base conveys a Schedule populated with Product
Descriptions and is extended to express additional market information
sufficient to define Products. All EMIX Products are derived from EMIX Base,
but not all derived types are Products. Along with the Schedule, EMIX Base
includes an optional Envelope (see 3.1.5).
|
Conforming specifications can extend the EMIX specification
for use in their own domain by extending the core types of EMIX. Within this
specification, Electrical Power is a specific extension of EMIX for power markets.
Specifications to support energy markets can be created through extension in an
analogous manner.
Figure 3‑1: The Abstract Product Description Base Type
3.1.2 Price Base and its
extensions
Prices in today’s power markets may be communicated other
than as a simple price. The Price Base is a low level abstract type which is an
element in many other types. Price Base is an extensible type whose extensions
include not only a simple or absolute price, but other types that rely on
foreknowledge and computation. Unless otherwise specified (as it is in TeMIX
which is restricted to only the simple price), wherever an information model
requires a Price Base, any type derived from Price Base is supported.
Table 3‑2: Elements derived from Price Base
|
Element
|
Description
|
|
Price
|
This is the number that quantifies the
actual price per unit of the product.
|
|
Price
Multiplier
|
A Price Multiplier applied to a reference price produces
the actual price. Optionally includes a Market Context for the reference
price.
|
|
Price
Relative
|
A Price Relative is added to a reference price to compute
the actual price. Price Relative may be positive or negative. Optionally
includes a Market Context for the reference price.
|
For extension purposes, a conforming specification can
define a new price type that can be used in any EMIX type by extending the
abstract Price Base.
Figure 3‑2: Price Base and Extensions
EMIX describes Products whose value is tied to an exchange
of ownership or control at a particular location at a particular time. EMIX
expresses this locality using the EMIX Interface.
The EMIX Interface is where something transfers ownership.
In power, this may be a node or meter, an aggregation of nodes or meters, a
pair of nodes, or a geographic area. Other specifications can derive from the
base type to support their own needs.
The EMIX Interface is an abstract type. The EMIX Interface
can represent a meter or a computation; the EMIX Interface can be real or
virtual, the EMIX Interface can be a collection or a singlet.
Table 3‑3: The EMIX Interface.
|
Type
|
Description
|
|
EMIX
Interface
|
Abstract base class for the interfaces for EMIX Product
delivery, measurement, and/or pricing
|
|
Service
Area
|
The Service Area is the only Interface defined for all
derived schemas. The Service Area expresses locations or geographic regions
relevant to price communication. For example, a change in price for a power
product could apply to all customers in an urban area. Service Areas are
defined using [GML] in its simplest profile, i.e., level 0.
|
EMIX interfaces for specific products have product-specific
requirements or have characteristics already defined in specific markets.
Within this specification, the EMIX Interface has specific extensions for Power
markets defined in Section 8.1 “EMIX Interfaces for Power”. Other markets can extend the EMIX Interface to support their specific needs.
Figure 3‑3: Summary of EMIX Interfaces including
both Emix and Power
The Item Base is the basis for the lowest level description
of each Product and its aspects. The term Item is in common business use for
that thing on a line of a purchase order, or of a receipt, or on a bill of
lading. Item Base derived types have at least a name, a unit of measure, and a
scale factor. The power schema (see 0 See Figure 3‑3: Summary of EMIX
Interfaces including both Emix and Power for all Interfaces defined in this
specification.
Power Items derived from Item Base) defines three power
types derived from the Item Base Type.
Items, i.e., types derived from Item Base, reference the
International System of Units (SI) to specify a set of alphabetic prefixes
known as SI prefixes or metric prefixes. An SI prefix is a name that precedes a
basic unit of measure to indicate a decadic multiple or fraction of the unit [SI
Units].
EMIX requires that conforming specifications use the SI
Scale to indicate the size of the unit of measure. The SI Scale is in the
external code list siscale.xsd.
3.1.5 The Envelope Contents
While energy markets actually deliver a blended commodity,
the customer may value the product differently based upon extrinsic
characteristics of the commodity. This distinction may be based, for example,
upon the origin of the product or upon its means of production. The product may
come with attached credits that may have re-sale value. The buyer may contract
for, and the supplier may need to report specific quality of product delivery.
In other circumstances, it may be necessary to deliver supporting detail to
explain the prices delivered.
In EMIX, the assertions that distinguish the commodity
product are called EMIX Warrants. A common definition of a warrant is a written
assurance that some product or service will be provided or will meet certain
specifications. Sellers may use EMIX Warrants to provide information about the
source of the energy or about its environmental characteristics. Buyers may use
EMIX 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 information models, including
EMIX Warrants, can support such market rules.
Figure 3‑4: Envelope Contents
EMIX Warrants are described in section 15. For now, it is sufficient to know that EMIX Warrants are delivered as Envelope Contents.
The communication of a commonly understood Schedule is
essential to EMIX. EMIX is conformant with the [WS-Calendar]
specification for communicating duration and time to define a Schedule. [WS-Calendar]
itself extends the well-known semantics [RFC5545].
Without an understanding of certain terms defined in [WS-Calendar],
the reader may have difficulty achieving complete understanding of their use in
this standard. The table below provides summary descriptions of certain key
terms from that specification. EMIX does not redefine these terms; they are
here solely as a convenience to the reader.
Table 3‑4: WS-Calendar defined Terms used in
EMIX
|
WS-Calendar Term
|
Description
|
|
Component
|
In [iCalendar], the primary information structure
is a Component, also known as “vcomponent.” A
Component is refined by Parameters and can itself contain Components. Several
RFCs have extended iCalendar by defining new components using the common
semantics defined in that specification. In the list below, Interval, Gluon,
and Availability (Vavailability) are Components. Duration, Link, and
Relationship are Parameters. A Sequence is set of Components, primarily
Intervals and Gluons, but is not itself a Type.
|
|
Duration
|
Duration is the length of an event scheduled using
iCalendar or any of its derivatives. The [XCAL] duration is a data
type using the string representation defined in the iCalendar ([RFC5545])
Duration.
|
|
Interval
|
The Interval is a single Duration derived from the common
calendar Components as defined in iCalendar ([RFC5545]). An Interval
is part of a Sequence.
|
|
Sequence
|
A set of Intervals with defined temporal relationships.
Sequences may have gaps between Intervals, or even simultaneous activities. A
Sequence is re-locatable, i.e., it does not have a specific date and time. A
Sequence may consist of a single Interval, and can be scheduled by scheduling
that single Interval in that sequence.
|
|
Gluon
|
A Gluon influences the serialization of Intervals in a
Sequence, through inheritance and through schedule setting. The Gluon is
similar to the Interval, but has no service or schedule effects until applied
to an Interval or Sequence.
|
|
Artifact
|
The thing that occurs during an Interval. [WS-Calendar]
uses the Artifact as a placeholder. EMIX Product Descriptions populate
Schedules as Artifacts inside Intervals.
|
|
Link
|
A reference to an internal object within the same
calendar, or an external object in a remote system. The Link is used by one [WS-Calendar]
Component to reference another.
|
|
Relationship
|
Links between Components.
|
|
Availability
|
Availability in this specification refers to the
Vavailability Component, itself a collection of recurring Availability
parameters each of which expresses set of Availability Windows. In this
specification, these Windows may indicate when an Interval or Sequence can be
Scheduled, or when a partner can be notified, or even when it is cannot be
Scheduled.
|
|
Inheritance
|
A pattern by which information in Sequence is completed or
modified by information in a Gluon.
|
Normative descriptions of the terms in the table above are
in [WS-Calendar].
Using the relation between Gluon and Sequence in
WS-Calendar, external information can be applied to an existing Sequence. For
example, a resource representing a responsive load may state that 15 minutes
lead time is required between notification and load reduction. This
characteristic may hold true whether the response requested is for a run-time
of 10 minutes or for one of 10 hours. EMIX specifies invariant characteristics
as part of a product description or resource, while offering the variable
run-time to the market.
A Sequence populated with product descriptions is referred
to as a Schedule. Because Schedules embody the same calendaring standards used
by most business and personal calendaring systems, there is a base of
compatibility between EMIX communications and business and personal systems.
For example, the Power Product (see section 10 Power Product Descriptions), an EMIX Base-derived type, may convey a Product Description for a
constant rate of delivery power product over a single Interval 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 exchanged in advance, the
information exchanged to deliver the product is simply “start (reference [URI]
to product) at 3:00 AM for 0.75 hours.”
3.3
Simple Semantic Elements of EMIX
A number of simple semantic types appear throughout this
specification. These are defined here.
Table 3‑5: Simple Semantic Elements of EMIX
|
Element
|
Definition
|
|
Market Context
|
A URI uniquely identifying a source for market terms,
market rules, market prices, etc. The URI may or may not resolve.
|
|
Transactive State
|
An indicator included in an EMIX Base derived types to aid
in processing. The enumerated Transactive States are: Indication Of Interest,
Tender, Transaction, Exercise, Delivery, Transport Commitment, and
Publication.
|
|
Currency
|
Market expressions of price are in the context of a
particular currency. Currency is always expressed as the [ISO 42173] Alpha
Currency Code.
|
|
Side
|
An indicator of the interest of the party originating the
artifact. Possible enumerations are Buy and Sell.
|
|
Integral Only
|
An indication that the element described is [tendered] as
an all or nothing product. It may apply to an (amount, response, ramp) that
is all (true) or nothing (false).
|
|
Autonomous
|
An indicator that the tendering party is able to detect a
need and self-dispatch to meet or correct that need.
|
|
Envelope
|
A generic name for all of the
EMIX-Base derived types.
|
Normative descriptions of the terms in the table above are
in [WS-Calendar].
3.4 Extensibility of EMIX
Framework
EMIX is modular by design. EMIX can be extended in
conforming standards. Information models from EMIX-conforming standards can be
exchanged in any interaction designed to exchange EMIX information models.
New efforts can specify novel Product Descriptions by
extending the EMIX Product Description Type. For example, district energy
systems distribute and transact thermal energy products. A district energy
group could define an EMIX-compliant product definition. These definitions
could be used to populate the Schedule of an EMIX Product or EMIX Option
without re-considering any aspects of the EMIX specification itself. A
specification used to exchange EMIX information could exchange these new
information models without change.
Warrants can evolve in a similar way. Some postulate that
water costs of energy sources may be of more future interest than the Warrants
anticipated in this specification. A water Warrant can be defined that extends
the Base Warrant type. This water Warrant can accompany EMIX information models
inside the envelope without any change to the underlying specification.
The Power and Resource schemas are, in effect, the first
extensions to the EMIX Schema.
Extensibility mechanisms supported in EMIX are discussed in
Appendix B.
4
Envelopes: EMIX Base and its Derivatives
EMIX describes the market communications of tenders and
transactions for products whose market value varies with time. An energy
product is delivered over time at a specific location. Five kW at 2:00 AM does
not have the same value as five kW at 2:00 PM due to differences in its
composition and potential usage by individual consumers. 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.
A Product Description included in each Interval in a
Sequence could describe similar elements repeatedly. 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. A Sequence populated
with product descriptions is referred to as a Schedule.
Figure 4‑1: UML of EMIX Base and its Extensions
4.2
The EMIX Base
The EMIX Base, as defined in Table 3‑1: EMIX Core Abstract Types and shown in Figure 4‑1: UML of EMIX Base and its Extensions is
the foundation for the Envelopes. The EMIX Base conveys a [WS-Calendar]
Sequence populated with Product Descriptions. This populated Sequence,
sometimes referred to as the Schedule, provides a flexible information model
for describing any energy tender or transaction.
Figure 4‑2: EMIX Base Type
There are three types of Envelopes defined in EMIX: the
Product, the Option, and the Delivery. Sections 4.3-4.5 define the information
on the “face of the envelope”, also referred to as the Intrinsic Information.
The Envelope Contents, also referred to as the Extrinsic Information, are
discussed in Section 15.
Table 4‑1: Elements of the EMIX Base.
|
Element
|
Definition
|
|
|
UID
|
A unique identifier for an EMIX element. Note: different
markets and specifications that use EMIX may have their own rules for
specifying a UID.
|
|
Schedule
|
A [WS-Calendar] Sequence populated with a
Product Description. See Table 3-1.
|
|
|
Envelope
Contents
|
The extrinsic information that may distinguish the
product from being a pure commodity. See Section 3.1.5.
|
|
New or specialized products can be offered and transacted
without changing the EMIX standard. A new Type can be derived from the Product
Description, be applied to a Schedule, and conveyed with EMIX Envelope.
4.3 The EMIX Product
The EMIX Product is derived from the EMIX Base type and
conveys a Schedule as described in Section 4.2. Section
2.1.1 discusses terminology and characteristics of a Product as defined in this
specification.
Figure 4‑3: EMIX Product
The EMIX Product is the most common of the envelopes. It is
used for simple tenders and agreements. It describes specific product delivery.
Table
4‑2: Elements of the EMIX Product
|
Product Element
|
Description
|
|
EMIX
Base
|
Incorporated
EMIX Base Type. See Table 4‑1: Elements of the EMIX Base.
|
|
Transactive
State
|
As defined in Table 3‑5: Simple Semantic Elements
of EMIX.
|
|
Tender
Expiration Date
|
The date
and time when a Tender expires. Meaningful only when the value of Transactive
State is Tender.
|
|
Integral
Only
|
Indicates that Schedule is accepted entirely or not at
all. Meaningful only when the value of Transactive State is Tender.
|
|
Market
Context
|
As defined in Table 3‑5: Simple Semantic Elements
of EMIX.
|
|
Side
|
Buyer or Seller.
|
|
Currency
|
Currency denominating product, Table 3‑5: Simple Semantic Elements of EMIX.
|
|
Terms
|
A
collection of business and performance rules that define the product
offering. See Section 5, “EMIX Terms”.
|
4.4
The EMIX Option
The EMIX Option is an elaboration of the EMIX Product
described above. An option is an instrument that gives the buyer the right, but
not the obligation, to buy or sell a product at a set price during given time windows.
Many typical energy agreements, including demand response and reserves, include
elements that would give them the name option in any other market.
Figure 4‑4: EMIX Option Type
The EMIX Option also conveys specific availability and
performance. The “face of the Envelope” contains additional information to
support these requirements.
Table 4‑3: EMIX Option Elements – another
"Face of the Envelope"
|
Option Element
|
Description
|
|
EMIX
Base
|
Incorporated
EMIX Base Type. See Table 4‑1: Elements of the EMIX Base.
|
|
Transactive
State
|
As defined in Table 3‑5: Simple Semantic Elements
of EMIX.
|
|
Tender
Expiration Date
|
The date and time when a Tender expires. Meaningful only
when the value of Transactive State is Tender.
|
|
Market
Context
|
As defined in Table 3‑5: Simple Semantic Elements
of EMIX.
|
|
Currency
|
Currency denominating product, Table 3‑5: Simple Semantic Elements of EMIX.
|
|
Terms
|
A
collection of business and performance rules that define the product
offering. See Section 5, “EMIX Terms”.
|
|
Integral
Only
|
Indicates that a Schedule is accepted entirely or not at
all. Meaningful only when the value of Transactive State is Tender.
|
|
Option
Exercise Schedule
|
The
schedule of time windows for the option expressed using the “Availability
Schedule” in Terms. See Section 5.2.
|
|
Option
Holder Side
|
The side which enjoys the benefit of choosing whether to exercise the
terms specified in the option.
|
|
Option
Premium
|
The Price paid by the Option Holder Side for the rights
involved.
|
|
Option
Strike Price
|
The Price that the Option Holder Side pays to exercise
the option.
|
|
Exercise
Lead Time
|
The
minimum Duration in advance of a proposed response that a notification will
be accepted for the exercise of the option. Expressed using the “Minimum
Notification Duration” in Terms. See Section 5.1.
|
|
Side
|
Identifies
whether information originator is on the Buy or Sell side.
|
|
Option
Type
|
An
enumerated list of Option types.
|
4.5
EMIX Delivery
Figure 4‑5: Delivery
In any market, order must be matched to delivery. EMIX
Delivery reports the historical delivery of product over time.
Table 4‑4: Elements of the EMIX Delivery
|
Delivery Element
|
Description
|
|
EMIX
Base
|
Incorporated
EMIX Base Type. See Table 4‑1: Elements of the EMIX Base.
|
|
Injection
|
True means
positive Delivery is injection into the grid. False means positive Delivery
is extraction from Grid
|
EMIX Products can be subject to a number of Terms and Market
Requirements. These Terms can apply at each transactive state. Terms are
extensible, so additional schemas, specifications, and standards can extend the
list while remaining in conformance.
Terms are extrinsic to the product delivery but affect how a
partner may request performance of a service. Terms may originate in the basic
mechanical needs of the Resource or in the business needs of the source. These
Terms can affect the market value of the resource or the repeated invocation of
a resource. It is possible for a given underlying resource to be offered to the
market with different terms and therefore different values.
5.1 EMIX Performance Oriented
Terms
Some terms indicate the ability of a side to perform. As
many market interactions may have a penalty for non-performance or for
performance that is not timely, it is essential for parties using EMIX
information to negotiate services to be able to define performance.
Table 5‑1: Performance-Oriented Terms
|
Term
|
Description
|
|
Minimum
Response Duration
|
The
shortest Duration for which a request will be accepted.
|
|
Maximum
Response Duration
|
The
longest Duration for which a request will be accepted.
|
|
Minimum
Recovery Duration
|
The
minimum Duration after completion of a response before a new response can be begun.
|
|
Minimum
Duration Between Invocations
|
The
minimum Duration between successive responses that will be accepted.
|
|
Minimum
Notification Duration
|
The minimum
Duration in advance of a proposed response that a notification will be
accepted.
|
|
Maximum
Notification Duration
|
The
maximum Duration in advance of a proposed response that a notification will
be accepted.
|
|
Response
Time
|
Duration
required from receipt of a request to supplying the full requested level of
response; i.e., notification time plus response time.
|
|
Maximum
Invocations Per Duration
|
Maximum
number of requests for response that will be accepted during a Duration.
|
|
Maximum
Consecutive Durations
|
Maximum
consecutive Durations in which a notification will be accepted; e.g., it will
not accept requests on more than three consecutive days.
|
|
Maximum
Run Duration
|
Maximum
acceptable Duration for a proposed response
|
|
Minimum
Run Duration
|
Minimum
acceptable Duration for a proposed response
|
5.2
EMIX Schedule Oriented Terms
Schedule related terms indicate schedules when a product may
be available or when an interaction may occur. A product may only be available
on weekends, or a party may not be able to respond outside of normal office
hours.
Table 5‑2: Schedule-Oriented Terms
|
Term
|
Description
|
|
Availability
Schedule
|
A schedule
of time windows during which a response may be scheduled. A scheduled
Duration must be entirely within a single instance of an availability window.
|
|
Unavailability
Schedule
|
A schedule
of time windows for which no request for response will be accepted. No part
of a requested Duration must coincide with an unavailability window.
|
|
Notification
Schedule
|
A schedule
of time windows during which requests can be made.
|
Market Requirements are terms
tied to the economic expectations expressed in certain market tenders. Market
Requirements are the market portion of Terms, i.e., they are used to state the
offeror's expectations about a tender. It is possible for a given underlying
resource to be offered to the market with different Requirements and therefore
different values.
Table 5‑3: Market Requirements for EMIX Products
|
Market Requirement
|
Description
|
|
Market
Granularity
|
The size
of a market “bundle”. For example, a Market with a granularity of 10 MW, will
only accept tenders, process transactions, and pay for delivery of Power in
multiples of 10MW.
|
|
Minimum
Economic Requirement
|
Minimum
net remuneration for any single response
|
|
Required
Startup Remuneration
|
Minimum
remuneration required for initiating a response.
|
|
Minimum
Starts Per Duration
|
The fewest
requests that the resource will accept during any Duration.
|
|
Minimum
Remuneration Rate
|
Minimum
remuneration acceptable per stated Duration of response. For example, a
minimum remuneration of $100 per hour.
|
The EMIX Terms above are not tied to any particular kind of
Product or Resource. All are based on the abstract Base Term type.
Specifications that require additional terms can create them by extending the
Base Term Type to create new terms.
Specific Terms for use with Power Products created by
extending the Base Term Type are found in Table 13‑2: Terms unique to Power Resources.
Figure 5‑1: Summary of EMIX Terms
6 Schedules
in EMIX: Intervals, Gluons, and WS-Calendar
This section discusses how EMIX uses [WS-Calendar] to
create Schedules. EMIX does not “schedule”. EMIX includes information to
communicate Schedules. Algorithms and methods are completely outside the scope
of EMIX. EMIX uses [WS-Calendar] to create information models that
describe schedules and that are populated with Product Descriptions. The
Semantics drawn from [WS-Calendar] are summarized in Table 3‑4: WS-Calendar defined Terms used in EMIX. This section
describes how EMIX uses the recombination and conformance rules from [WS-Calendar]
to create Schedules.
Types derived from the abstract EMIX Base contain a
Schedule created by populating a Sequence with Product Descriptions. The terms
Duration, Interval, Sequence, and Gluon are defined in [WS-Calendar]. [WS-Calendar]
defines a model for inheritance wherein a fixed description of a product is
refined with additional information as it becomes actionable. The Intervals in
a Sequence can inherit information from a Gluon related to that Sequence.
The iCalendar standard, with which [WS-Calendar]
conforms, is an information model of a “bag of Components”. Each Component can
include an attachment for passing some kind of information. Intervals and Gluons
are two of the [WS-Calendar] Components. The schema type for Product
Descriptions is derived from the attachment so Product Description-derived
types are valid contents of these Components.
In [WS-Calendar], a Gluon relates to a Sequence by
relating to a specific Designated Interval within that sequence. All other
Intervals have defined temporal relationships, directly or indirectly, to the
Designated Interval. If a Gluon contains a start date and time, that start date
and time is inherited only by the Designated Interval; the start dates and
times for all other Intervals in the Sequence can be computed from that single
date and time. In this way, a set of Intervals containing EMIX Product
Descriptions can define what is in effect a schedule sub-routine, invoked by
starting the Designated Interval.
In EMIX, when a Gluon contains a Product Description, it can
then be inherited by each of the Intervals. If an Interval already contains a
Product Description, then it refuses the Inheritance from the Gluon. This model
of inheritance mimics that defined in [WS-Calendar] for inheriting
Duration.
Duration, Product Description, Price, and Quantity for each
Interval in a Sequence can each be inherited from a Gluon in EMIX. The Start
Date and Time can be inherited only by the Designated Interval. This follows
and extends the rules of inheritance defined in [WS-Calendar].
There is no requirement for the Designated Interval to be
the “first” interval. If a Sequence describes a ramp-up, peak operation (of
whatever service), and ramp down, it may be more useful to designate the
Interval containing peak operation. In this scenario, the Durations of all
Intervals other than the Designated Interval may be fixed, that is encoded in
each interval. A communication to “start” the Sequence, then, could contain the
start date and time and the run Duration.
The rules of inheritance are described in Section 17.1 EMIX Conformance with [WS-Calendar. Inheritance in [WS-Calendar]
is described in that specification.
[WS-Calendar] defines the expression of the
Vavailability information model for repeating instances of time (Availability
Windows) within a period that may or may not have an end date. Vavailability is
a Component of iCalendar. EMIX uses Vavailability primarily in Terms.
One party MAY use Vavailability to indicate to another party
when a service can be requested. This may be a contracted part of an EMIX
Option or it may define the Demand Response window (afternoons during summer
months) of a regulated tariff. EMIX does not define the interactions or
negotiations that lead to either of those circumstances.
Availability communicates acceptable schedule times for
Sequences. The semantics of scheduling a Sequence to comply with previously
stated Availability in [WS-Calendar] is that the Designated Interval
must be inside one of the Availability Windows. While it is possible that not
all information regarding Intervals in a Sequence may be exposed in
interactions, a party requesting an EMIX product does know the Duration and
Start Date and Time of the Designated Interval.
WS-Calendar EMIX are information models, and do not create
market rules or define interactions. The specification makes no statement about
how a market, or even how a market participant handles receipt of a Schedule
which does not comply with a stated availability. Such an Availability and
Schedule are likely in separate communications, each containing valid
informational artifacts. The word “comply” in the previous paragraph describes
the meaning of the information exchanged, and not any behavior or market rule.
Again, see [WS-Calendar] for a complete description.
[WS-Calendar] defines temporal Granularity which is
expressed as a Duration. When Granularity is applied to a Vavailability object,
then:
1) The valid
start times are offsets from the start of the availability window that are
integral multiples of that duration. For an Availability of 14:00 to 16:00,
with a granularity of fifteen minutes “PT15M”, there are 8 valid
starting times (14:00, 14:15, 14:30, 14:45, 15:00, 15:15, 15:30, 15:45).
2) If
duration is specified by the requestor, it must be an integral multiple of the
Granularity. In the example above, “PT15M”, “PT30M”, “PT45M”, “PT1H”, PT1H15M”,
etc. are valid Durations.
3) The Start
Date and Time plus the Duration must complete no later than the end of the
Availability window.
6.4 Illustration of WS-Calendar and EMIX
The illustration below provides a model demonstrating a
sequence of three Intervals, and the successive application of Gluons to bring
them to market.
Figure 6‑1: EMIX Schedule and Building a Product
In any market context, there are standing terms and
expectations about product offerings. If these standing terms and expectations
are not known, many exchanges need to occur of products that do not meet those
expectations. If those expectations are only known by local knowledge, then then
national and international products need to be re-configured for each local
market that they enter. If all market information is transmitted in every
information exchange, messages based on EMIX would be repetitious.
As defined in Table 3‑5: Simple Semantic Elements
of EMIX, a Market Context is no more than a URI uniquely identifying a
source for market terms, market rules, market prices, etc. This section defines
an information model for the common rules and expectations for all interactions
within a single Market Context.
Standard Terms defines an information model for exchanging
these common expectations outside of any single product-related artifact. The
TC acknowledges that these can be only a small portion the total market rules.
The basis of Standard Terms is the Standard Terms Set shown
in the following table.
Table 7‑1: Elements of the Standard Term Set
|
Component
|
Description
|
|
Terms
|
A collection of Terms as defined in Section 5: EMIX Terms.
|
|
Availability
|
[WS-Calendar] Vavailability (see Table 3‑4: WS-Calendar defined Terms used in EMIX) indicating when this Market Term Set is
valid, i.e., weekdays from 11:00 AM to 6:00 PM.. If absent, the Market Term
Set is valid at all times.
|
|
Non-Standard Terms Handling
|
A string enumeration indicating how to handle terms
received that are different than those in the Market Term Set. Permissible
values are: Reject (the information artifact), Ignore (the terms), Must
Understand, Must Accept.
|
|
Side
|
“Buy” or “Sell”. Note: Some Terms can have different
interpretations based on who is offering them. A Buyer may indicate
"meet or exceed" while a seller expressing the same term may
indicate "no worse than".
|
Standard Terms Sets can be assembled with other information
to create the Standard Terms shown in the following table.
Table 7‑2: Elements of Standard Terms
|
Element
|
Description
|
|
Market Context
|
URI uniquely identifying context, per Table 3‑5: Simple Semantic Elements of EMIX.
|
|
Standard Terms Set
|
Zero (0) to many. As defined in Table 1‑1
|
|
Product Description
|
As defined in Table 10‑1: Summary of Power
Product Description Types. If present, this is the only Product
Description in this market context. If Product Quantity is included, it SHALL
be ignored.
|
|
Temporal Granularity
|
As defined in [WS-Calendar]. For example, this may
be the temporal granularity of market; i.e., a 5-minute market operates in 5-minute
chunks, with a fixed offset from the beginning of the Availability time
window.
|
|
Time Zone
|
TZID as defined in [WS-Calendar]. Time Zone for
communications in this market. Note: this applies to "floating"
time, that is expressions of time that are not in UTC or do not have a Time
Zone indicated.
|
|
Currency
|
Currency for all information models. If present, becomes
the default for all information models. As defined in Table 3‑5: Simple
Semantic Elements of EMIX.
|
|
Non-Standard Terms Handling
|
As defined in Table 7‑1: Elements of the Standard
Term Set
|
Specifications that claim conformance with EMIX MAY define
inheritance patterns by which EMIX compliant information models inherit certain
information from the Standard Terms.
Figure 7‑1: Standard Terms
8
Extending EMIX for Electrical Power
EMIX provides an abstract information model that can be
extended to convey Price and Product information for commodities whose value
varies with the time and location of delivery.
The EMIX Power schema (POWER.XSD) can be viewed as the first
extension of EMIX into a particular domain. The schema extends the Base EMIX
Product Descriptions to define a variety of power products, in particular
extending the Item Base to create Items for Real Power, Apparent Power, and
Reactive Power among others. The schema derives new Product Descriptions
products with ways to describe levels and tiers.
Electrical power markets have their own definitions for
where the transaction occurs. The EMIX Power schema (POWER.XSD) extends the
EMIX Interface to accommodate these definitions.
The resulting extensions can populate a Schedule and define
EMIX Products, Options, and Delivery.
8.1 EMIX Interfaces for Power
Every market transaction occurs at an interface, where
beneficial rights to or use of a product are transferred between buyer and
seller. This is often the point at which the flow of product is measured
although it may not be.
In power markets, described in the sections below, the Interface
can be a node or meter, an aggregation of nodes or meters, a pair of nodes, or
a geographic area. The Service area defined in the underlying EMIX.XSD schema
is also available for use by power-based products.
Table 8‑1: Elemental types of EMIX Interfaces
defined in POWER
|
Elemental Type
|
Description
|
|
MRID
|
As defined
in the [IEC TC57], can identify a physical device that may be a
Customer Meter or other types of End Devices."
|
|
Node
|
As defined
in the [IEC TC57], a place where something changes (often ownership)
or connects on the grid. Many nodes are associated with meters, but not all
are.
|
Power Interfaces are, for the most part, named instances of
one of the elements above included in the EMIX Interface.
Table 8‑2: EMIX Interfaces defined in POWER
|
Power Interface
|
Description
|
|
EMIX
Interface
|
Each of
the interfaces below derives from the abstract class as defined in .
Table 3‑3:
The EMIX Interface.
|
|
Service
Area
|
Inherited
from EMIX schema. See .
Table 3‑3:
The EMIX Interface.
|
|
End
Device Asset
|
Physical
device or devices, which could be meters or other types of devices that may
be of interest. Examples of End Device Assets include a Meter Asset that can
perform metering, load management, connect/disconnect, accounting functions,
etc. Some End Device Assets may be connected to a Meter Asset.
|
|
Meter Asset
|
Physical
device or devices that perform the role of the meter.
|
|
Pricing
Node (PNode)
|
Pricing
location for which market participants submit their bids, offers, buy/sell
CRRs, and settle. Note: a pricing node is directly associated with a
connectivity node.
|
|
Aggregated
Pricing Node
|
Specialized
type of Pricing Node used to model items such as system zone, default price zone,
custom price zone, control area, aggregated generation, aggregated participating
load, aggregated non-participating load, trading hub, or DCA zone.
|
|
Service
Location
|
A location
on the network where the ownership of the service changes hands, expressed as
a [GML] Abstract Feature. Note: it potentially has many Service Delivery
Points, delivering service in accordance with a Customer Agreement. Each
Service Location may have zero to many Meter Assets.
|
|
Service
Delivery Point
|
Logical point on the network where the ownership of the
service changes hands. There is only one Service Location for each Service
Delivery Point, delivering service in accordance with a Customer Agreement.
Used at the place where a meter may be installed. Each Service Delivery Point
may have zero to many Meter Assets.
|
|
Transport
Interface
|
Delineates
the edges at either end of a transport segment. Note: unique among Interfaces
in that it names two Nodes rather than one: point of receipt and point of
delivery.
|
See Figure 3‑3: Summary of EMIX Interfaces including
both Emix and Power for all Interfaces defined in this specification.
Types derived from the abstract Item Base type are used not
only to quantify the items, but potential attributes of items as well.
The POWER.XSD schema defines a number of items to define the
exchange of POWER. These Power Items are derived from the abstract Power Item,
itself derived from Item Base.
Table 8‑3: Elements of the Power Item
|
Power Element
|
Description
|
|
Item
Base
|
Abstract
Item as defined in Table 4‑1: Elements of the EMIX Base.
|
|
Item
Description
|
Name of
the Power Item.
|
|
Item
Units
|
String
representation of Units.
|
|
Scale
Code
|
Alphabetic
representations of Scale from the SI Scale code list; e.g., M for Mega, K for
Kilo, etc.
|
|
Power
Attributes
|
Gross
attributes of Power: AC/DC, Hertz, nominal Voltage.
|
The named Items derived from the Power Item type are shown
in the table below.
Table 8‑4: Defined Power Items
|
Item Name
|
Units
|
Description
|
|
Real
Power
|
W or J/s
|
Real power,
expressed in Watts (W) or Joules/second (J/s).
|
|
Reactive
Power
|
VAR
|
Reactive
power, expressed in volt-amperes reactive (VAR).
|
|
Apparent
Power
|
VA
|
Apparent power,
expressed in volt-amperes (VA).
|
Figure 8‑1: UML Summary of Power Items
Types derived from the abstract Item Base type are used not
only to quantify the items, but potential attributes of Energy as well.
The POWER.XSD schema defines a number of items to define the
exchange of electrical energy. These Energy Items are derived from the abstract
Energy Item, itself derived from Item Base. The following table enumerates the
Energy Elements.
Table 8‑5: Elements of the Energy Item
|
Energy Element
|
Description
|
|
Item
Base
|
Abstract
Item as defined in Table 4‑1: Elements of the EMIX Base.
|
|
Item
Description
|
Name of
the Energy Item.
|
|
Item
Units
|
String
representation of Units.
|
|
Scale
Code
|
Alphabetic
representations of Scale from the SI Scale code list; e.g., M for Mega, K for
Kilo, etc.
|
The named Items derived from the Energy Item type are shown
in the following table.
Table 8‑6: Defined Energy Items
|
Item Name
|
Units
|
Description
|
|
Real
Energy
|
Wh or J
|
Real energy,
expressed in Watt Hours (Wh) or Joules (J).
|
|
Reactive
Energy
|
VARh
|
Reactive energy, expressed in volt-amperes reactive hours
(VARh).
|
|
Apparent
Energy
|
VAh
|
Apparent energy, expressed in volt-ampere hours (VAh).
|
Many types in POWER.XSD derive from the Item Base. Figure 8‑2 shows the Energy Item Type, from which Real Energy, Apparent Energy,
and Reactive Energy are derived.
Figure 8‑2: UML summary of Energy Item Types
8.4
Other Item-derived types
Voltage is another type in POWER.XSD derived directly from
the underlying Item Base. The Elements of Voltage are shown in the table below.
Table 8‑7: Voltage as an Item
|
Voltage Element
|
Description
|
|
Item
Base
|
Abstract
Item as defined in Table 4‑1: Elements of the EMIX Base.
|
|
Item
Description
|
Voltage
|
|
Item
Units
|
V
|
|
Scale
Code
|
Alphabetic
representations of Scale from the SI Scale code list; e.g., M for Mega, K for
Kilo, etc.
|
9 EMIX
Power Product Descriptions
This section provides a guide to the rest of the Specification.
Electrical power and energy must be described precisely as
it comes to market. Different products can provide total power, real power, or
reactive power. Products delivering the same Power at a different voltage, or
in DC rather than AC, may be valued differently. For the convenience of the
readers, terms associated with electrical power and energy, and the
relationships between them, are reviewed in Appendix E.
EMIX provides an information model for exchanging Price and
Product information for power and energy markets, where the value of the
Products is tied closely to the time of delivery. EMIX Power defines specific
EMIX Products for Power delivery. EMIX Resources define capabilities that could
be brought to market and the performance characteristics those resources will
have, and thus enable a buyer to determine with which resources to seek
agreements.
EMIX Products consist of Product Descriptions applied to the
EMIX Base Product. There are three classes of Product Description defined as:
1) Power Product Descriptions
2) Resource Offer Descriptions
3) Transport Product Descriptions
EMIX Power Products are defined using standard attribute
definitions from [IEC TC57], where the canonical definitions also
reside.
9.1 Power Product
Descriptions
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”). While the underlying commodity good is identical, the
Product is differentiated based on how it is purchased. Common distinctions
include:
a) Specify
the rate of delivery over a Duration.
b) Specify the
amount of energy over an Interval with no restrictions on the rate of delivery
at any instant within the Interval.
c) Made
available as Full Requirements Power, the same as b, except that the amount of
energy transacted is measured after delivery.
Product Descriptions for transacting Power are found in
Section 10 “Power Product Descriptions”
9.2 Resource Offer Descriptions
Resources include generators that can produce power and
other services, storage devices that can consume, store and then produce power,
and loads that produce power through 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 13: Energy Resources.
9.3 Transport Product
Descriptions
Product Transport provides for the transport of a product
from one Interface location to another generally using transmission and
distribution facilities. Transport prices may cover recovery of investment and
energy loses incurred during transport as well as congestion prices. A single
price may characterize a Transport Product or a set of charges. Product
descriptions for Transport are discussed in Section 11 Power Transport Product Description.
10 Power Product Descriptions
The information model in this section is described in
POWER-PRODUCTS.XSD
Almost all Power Products are based on core abstract class,
the Power Product Description. The Power Products also share core semantic
elements, used throughout the Descriptions and their associated charges.
Several of these were described in Section 8: Extending EMIX for Electrical Power.
Figure 10‑1: UML Summary of Power Product Descriptions
The following sections define the Power Product
Descriptions. A summary of those descriptions is provided in the following
table..
Table 10‑1: Summary of Power Product Description Types
|
Name
|
Description
|
|
Product
Description
|
All Power
Product Descriptions are derived from the EMIX base Product Description type
See Table 3‑1: EMIX Core Abstract Types.
|
|
Power Product
Description
|
Used for
simple power transactions; also used as template for other Power Product
Description Types. After a specified duration, energy has been delivered at a
price per unit of energy.
|
|
Full Requirements
Power
|
Used to
provide for full requirements of buyer. Simple price, will supply all used.
Demand Charges optional. Often used in retail residential rates.
|
|
Block Power
Full Requirements
|
Used to
provide for full requirements of buyer in "blocks". Price is
constant within a block, but changes as each block is used during a period.
Demand Charges MAY be included. Often used in retail residential rates.
|
|
Transport
Product
|
Used for charges
and revenue related to Transport Services for a Power Product; i.e., the
movement of Power through Transmission and Distribution. The Interface used
matches a segment of the transport infrastructure, usually identified by an
injection node and a delivery node. Transport Products are discussed in
Section 11.
|
|
TeMIX Power
|
Used for a
specific sized block of Power at a constant rate of delivery. Derived
directly from EMIX Product Description rather than Power Product Description
because only Price and Quantity are required.
|
Because different Power Product Descriptions use the same
informational elements, and because different transaction states may not
require all elements be present in every exchange, each Power Product
Description includes a Power Contract Type. Different Power Contract Types MAY
have different conformance requirements in different market contexts.
Table 10‑2: Power Contract Types
|
Power Contract Type
|
Note
|
|
Energy
|
Block of Energy.
|
|
Transport
|
Block of Transport.
|
|
Energy Option
|
Option for Block of Energy.
|
|
Transport Option
|
Option for Block of Transport.
|
|
Full Requirements Power
|
Used for supplier to provide for full requirements of
buyer. Simple price, will supply all used. Often used in retail residential
rates.
|
|
Full Requirements Power with
Demand Charge
|
Similar to Full Requirements
except specific and perhaps recurring Demand Charges are incurred for
exceeding set demand limit(s).
|
|
Full Requirements Power with
Maximum and Minimum
|
Customer must draw power at no
less than the minimum rate and no more than the maximum rate during any
measurement Interval.
|
|
Hourly Day Ahead Pricing
|
Same as Full
Requirements Power but prices potentially change each hour.
|
|
Ex-Ante Real Time Price
|
Used to report prices after the fact.
|
|
Time of Use Pricing
|
Strategy where the price may change based on time of day
on a schedule set by the provider. The provider may define schedule and
pricing differences depending upon day of week, holiday or not, month of year
and season.
|
|
Transport Service
|
Used to acquire Transport including factors for
congestion, loss, charges, fees, etc.
|
|
Congestion Revenue Rights
|
Used to hedge against future Transport / Congestion costs.
|
|
Regulation Up
|
Instructed Injection of Energy
to Grid.
|
|
Regulation Down
|
Instructed Decrease of Energy to
Grid.
|
|
Spinning Reserve
|
Synchronized Reserve Product
|
|
Non Spinning Reserve
|
Non Synchronized Reserve Product
|
The Power Contract Type MAY be extended per the extensibility
rules. See Appendix B-1 for a discussion of extending string enumerations.
Power Products are often encumbered with a number of special
charges. Some charges may be intrinsic to the product, and specifically
incorporated into the Power Product Descriptions below. Others arise from
specific market conditions and can be applied through a generic charges
collection.
Each of the products from Table 10‑2, with the exception of TeMIX, can be
subject to one or more Power Charges. All Charges are based on the Base Charge
abstract type, meaning markets that require non-standard Charges have the means
to define extensions to the set of Power Charges.
Table 10‑3 summarizes
the Power Product Charges.
Table
10‑3: Power Product Charges
|
Charge Type
|
Description
|
|
Base
Charge
|
Null
abstract type from which all charges are derived.
|
|
Block Power Price
|
A Price and a Maximum Energy Quantity. When arranged in
order by Maximum Energy Quantity, they represent a set or prices for
different levels of Energy.
|
|
Demand Charge
|
Charges meant to offset infrastructure needed to support
peak use. The structure that describes a Demand Charge is described in
Section 10.1.2.1.
|
The Demand Charge as defined
above has a more complex structure than the other Charges. The Demand Charge is
defined in Table 10‑4: Elements of Demand Charges.
Table 10‑4: Elements of Demand Charges
|
Demand Charge Element
|
Description
|
|
Consumption Units
|
Units of product consumed upon which
Demand Charges will be computed.
|
|
Consumption Ceiling
|
Below this quantity, a Consumption
Penalty is not applied.
|
|
Consumption Penalty
|
Incremental charge applied if
Consumption Ceiling Floor is exceeded.
|
|
Measurement Interval
|
Duration over which average peak demand
is measured (e.g., 15 minutes, 30 minutes...)
|
|
Collection
Interval
|
Collection
of Measurement Intervals. Consumption Penalty is based on single highest
average peak demand taken from all the Measurement Intervals contained in the
Collection Interval.
|
|
Penalty
Period
|
Duration
to which the Penalty applies, often a billing cycle.
|
|
Penalty
Duration
|
Duration
during which consecutive Consumption Penalties will continue to be applied
after incurred.
|
10.1.2.2 Summary of Power Product Charges
Figure 10‑2: UML Summary of Power Product Charges
10.2
The Power Product Description
The Base Power Contract is the foundation for all the other
Power Contracts. Each of them has the characteristics of the Base Power
Contract plus their own additional elements:
Table
10‑5: Base Power Product Description
|
Name
|
Description
|
|
Product
Description
|
Base type
for derivation. See Table 3‑1: EMIX Core Abstract Types.
|
|
Power
Product Type
|
Used to
determine conformance and processing. See Table 10‑2
|
|
EMIX
Interface
|
See Table 8‑2: EMIX Interfaces defined in POWER.
|
|
Unit Energy Price
|
Price Base, see
Table 3‑2: Elements derived from Price Base.
|
|
Power Item
|
See Table 8‑4: Defined Power Items.
|
|
Charges
|
Any number of Charges as defined in Table 10‑3: Power Product Charges
|
Each Power Product is applied to the EMIX Base Product
before it is fully described. Because each element can be set for the whole
Sequence, or applied to individual Intervals, each can vary over time.
10.3
Full Requirements Power
Full Requirements Power
products are the traditional “all-you-can-eat” electrical contract. Maximum
delivery is limited by the physical infrastructure. Demand Charges may apply.
This type of product often appears in Residential markets.
As well as the attributes in
the base Power Contract, the Full Requirements Product has the elements defined
below.
Table 10‑6: Full Requirements Power Product
Description
|
Name
|
Description
|
|
Power
Product Description
|
As
described in Table 10‑5: Base Power Product Description.
|
|
Maximum Power
|
The most power available for transacting
during the period. Often determined by physical limits.
|
|
Minimum Power
|
The least power that must be transacted
during the Interval. Buyer is responsible
for making up the difference if the stated value is not consumed.
|
10.4 Block Power Full
Requirements
Block Power Full Requirements
products provide for full buyer requirement, but prices the power in “blocks”. Price
is constant within a block, but each block may have a different price within a
period. Demand Charges MAY be included. This type of Product is often used in
retail residential rates.
Figure 10‑3: Block Power Full Requirements
As well as the attributes in
the base Power Contract, the Block Power Full Requirements Product has these
additional elements:
Table 10‑7: Block Power Full Requirements
|
Block Power Element
|
Description
|
|
Power
Product Description
|
As
described in Table 10‑5: Base Power Product Description.
|
|
Maximum Power
|
Denominates the most power available for
transacting during the period.
|
|
Minimum Power
|
Denominates the least power that must be
transacted during the Interval. Buyer is
responsible for making up the difference if the stated value is not consumed.
|
|
Price Tiers
|
Any number of Block Power Prices as
described in Table 10‑3: Power Product Charges.
|
The TeMIX (Transactive Energy Market Information Exchange)
is a model for balancing power markets with pure economic trading. It uses the
simplest of the Power Product Descriptions.
The TeMIX profile allows only specific tenders and
transactions for block power on defined Intervals of time. Tenders may be
offered by any party to any other party, as market rules and regulations may
allow. Any party can be a buyer, seller, or both. Transactions may include call
and put options. TeMIX Options perform a similar function to demand response
contracts or ancillary service contracts where an operator has dispatch control
over the exercise of the option. TeMIX products also include transmission and
distribution (transport) products.
TeMIX tenders and transactions can support dynamic tariffs
by retail providers to retail customers. TeMIX is designed for interval
metering where delivery can be accurately measured. The simplified information
model and services of the TeMIX profile also support increased automation of
transactions using the computer and communications technology of the smart
grid.
TeMIX Products are specified by Power (rate of delivery of
energy) over an Interval. TeMIX Products are obligations in that a TeMIX
Product is a commitment by the seller to deliver and the buyer to take the
Power (Energy) over the Interval. When the Interval includes more than one
measurement or metering Interval, the TeMIX product is defined as a constant
rate over each of those metering Intervals. An example is the sale of 1 MW
tomorrow between 3 and 5 PM that may be measured every 15 minutes (The energy
is 1 MWh). The power in each 15 minute Interval is 2 MW and the Energy in each
15 minute Interval is 0.25 MWh. A position in a TeMIX product may be sold or
added to. Depending on local market rules, differences between the Power
purchased and the actual delivery may be delivered from or to spot markets at
spot market prices.
TeMIX is derived directly from the base Product Description
because TeMIX is simpler and with less optionality than other Power Product
Descriptions.
Table 10‑8: TeMIX Power Product Description
|
TeMIX Element
|
Description
|
|
Product
Description
|
Base type
for derivation. See Table 3‑1: EMIX Core Abstract Types.
|
|
Power
Product Type
|
Used to
determine conformance and processing. See Table 10‑2
|
|
EMIX
Interface
|
An EMIX
Interface is any of a number of market exchange points including a point, an
aggregate point, or a geographic area at which a product exchanges ownership
|
|
Price
|
Price per Unit of Energy. For TeMIX,
this is always the actual price and not an offset.
|
|
Energy Item
|
Total Energy being transacted. Energy
Type (Real, Apparent, or Reactive) must match Energy Type of Power Item.
|
|
Power Item
|
Rate of Delivery of Energy. Power Type
(Real, Apparent, or Reactive) must match type of Energy Item.
|
TeMIX Product-based
information exchanges are a little different from those for other products;
they are discussed by themselves in Section 12 Profile for Transactive Energy (TeMIX).
11 Power
Transport Product Description
The information model in this section is described in
POWER-PRODUCTS.XSD
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. Future markets,
including those for microgrids and virtual service providers, may not make the
same distinctions between transmission and distribution as have been made in
the past. Distributed Energy Resources (DER) may create new business models for
use of the existing distribution networks.
The information model below merges the charges and
approaches used in the respective transmission and distribution networks today.
It anticipates that potential source selection markets may result in passage
through multiple networks. The resulting Schedule can either stand-alone in transport
products, or be conveyed inside the Envelope as price support information, in
support of Locational Marginal Pricing (LMP).
Table 11‑1: Transport Description
|
Transport Product Element
|
Description
|
|
Point
of Receipt
|
Where
power enters a network or changes ownership.
|
|
Point
of Delivery
|
Where
power exits a network or changes ownership.
|
|
Price
|
As defined
in
Table 3‑2: Elements derived from Price Base.
|
|
Transport
Charges
|
An array of Transport Charges, as defined in .
Table 11‑2:
Transport Product Charges.
|
There MAY be multiple instances of the above Artifacts in a
single Price instance. For example, in a given transaction, power may pass
through multiple distribution nodes and congestion points.
The items listed in the table above are each derived from
the base charge type. All other charges, previously described, are available
for inclusion within a Transport Product.
Table 11‑2: Transport Product Charges
|
Charge Type
|
Description
|
|
Base
Transport Charge
|
A sub-set
of Charges for Transport-related Charges. Derived from Base Charge.
|
|
Congestion Revenue Rights
|
A financial hedge for congestion; i.e., a forward contract
for congestion revenues potentially to offset congestion charges. Also known
as financial transmission rights. (Transport Charge)
|
|
Congestion Charge
|
The cost of purchasing the right to transfer power over a
given segment of the grid. (Transport Charge)
|
|
Transport
Access Fee
|
A simple
charge (not dependent on congestion) to access transport system. (Transport Charge)
|
|
Transport Congestion Fee
|
Assessment per unit of energy
for energy flowing from receipt to delivery point. Can be a positive or
negative price. (Transport Charge)
|
|
Marginal Loss Fee
|
A Marginal Loss Fee is assessed per
unit of energy to pay to replace Power lost during transport. (Transport
Charge)
|
|
Transport
Loss Factor
|
A
multiplier applied to a transacted quantity of energy to reduce delivery quantity
due to loss during transport. (Transport Charge)
|
|
Conversion
Loss Factor
|
A multiplier applied to a transacted
quantity of energy to reduce delivery quantity due to loss as product voltage
is changed or as converted from AC to DC or DC to AC. (Transport Charge)
|
Figure 11‑1: UML Summary of Transport Charges
TeMIX is a profile of the EMIX Power Products. This section
describes the TeMIX profile. The EMIX TC has prepared a Committee Note [TeMIX]
that provides a context for the TeMIX profile.
The TeMIX model is based on blocks of Power with a constant
rate of delivery (subscription) over a single Interval. All TeMIX Products are
transactions for Power delivered over the course of a single Interval. Each
transaction imposes an obligation on the buyer to purchase and the seller to
deliver a TeMIX Power Product. This simplicity
reduces the number of products and interactions.
There are only four types of TeMIX
Products:
- TeMIX
Power Product
- TeMIX
Transport Product
- TeMIX
Option Power Product
- TeMIX
Option Transport Product
The Transactive States for a TeMIX Product are:
- Indication
of Interest
- Tender
- Transaction
- Delivery
- Price
Publishing
A TeMIX Delivery Interval is specified by a Duration and
Start Time. When a TeMIX Product specifies a set of Delivery Intervals, then the
elements that do not vary by Delivery Interval may be specified in a Gluon or
the Standard Terms. Each TeMIX Delivery Interval is transacted independently of
the others.
The rate of delivery of a TeMIX Power Product is constant
over all measured (metered) Intervals within a TeMIX Delivery Interval. For
example the transaction could be for 1 hour, but the meter reads every 5
minutes. These market rules are outside the scope of this specification/
For example, 1 MW of power transacted for delivery tomorrow
for two hours between 3 and 5 PM provides 1 MWh of energy over each hour and 2
MWh over the two hours. If delivery is measured every 15-minutes, then the
power transacted in each 15 minute Interval is 1 MW. The energy transacted in
each 15-minute Interval is 0.25 MWh. If the energy delivered in each 15-minute
Interval is greater or less than 0.25 MWh then the balance (positive or
negative) will be sold or purchased in a subsequent balancing transaction.
The Price of a TeMIX Product is expressed in energy units.
For the example above, when the price is $80 per MWh of energy, the extended
price (cost) of 1 MW of Power for two hours between 3 and 5 PM is $160; the
extended price for 1 MW of Power in each 15-minute Interval of the two hours is
$20.
A TeMIX Transport Product is a subscription for Transport
(transmission or distribution) to transport a TeMIX Power Product from one EMIX
Interface to another. A TeMIX Transport Product is a subscription for power
transport at a constant power over the interval.
A TeMIX Option Product provides the Option Holder the right
to instruct the option writer to deliver (call) or take (put) a TeMIX Power or
Transport Product up to the transacted quantity (rate of delivery) of the
Option at a Strike Price.
TeMIX Options are either Call or Put Options on TeMIX Power
and Transport Products. A TeMIX Option can be exercised during the Delivery
Interval of the Option for any sub-Interval not smaller than the Option
Interval Granularity.
For example, a TeMIX Option for 10 MW for a Day and an
Option Interval Granularly of 1-hour and an Option Lead Time of 30 minutes
would allow the Holder to exercise the option for any or all hours of the Day
at the Strike Price by giving notice 30 minutes before each hour.
The elements of a TeMIX Power and Transport Product are
shown in Table 11‑1: Transport Description. When the Product Description
(from the Section Power Product Descriptions) is applied to the EMIX
Base types, the TeMIX elements are as shown in that table.
Table 12‑1: TeMIX Product Description
|
TeMIX Element
|
Description
|
|
Power
Product Type
|
Enumerated
type of Power Product. Used to determine conformance requirements.
|
|
EMIX
Interface
|
The
Interface where the transaction occurs. Generally, the Interface for a Power
Product has one node and the Interface for a Transport Product has two nodes.
|
|
Start Date and Time
|
When the Interval begins.
|
|
Duration
|
The extent of time of the Interval.
|
|
Price
|
The Unit Energy Price for the Interval.
TeMIX does not allow Relative Prices or Price Multipliers.
|
|
Energy Item
|
Total Energy (Power * Time), Real,
Apparent, or Reactive, delivered over the Interval.
|
|
Power Item
|
Units for the Rate of Delivery of Energy
for the Delivery Interval. Includes Power Attributes.
|
|
Power Quantity
|
Rate of Delivery of Energy for the
Delivery Interval.
|
|
Transactive State
|
TeMIX Transactive state is conformed to Indication
of Interest, Tender, Transaction, Delivery or Publish.
|
|
Currency
|
Currency for the exchange.
|
|
Side
|
Indicates which side of the agreement
the information originator is on. Buy or Sell.
|
|
Expires Date
|
Date and Time Tender expires. Not
present if the Transactive State is anything other than Tender.
|
|
Envelope
|
As defined in Section 3.1.5: The Envelope Contents.
|
The TeMIX Option extends the TeMIX Product by adding these
additional elements:
Table 12‑2: TeMIX Power Option Product Description
|
TeMIX Element
|
Description
|
|
Option
Holder Side
|
The side
(buy or sell side of the option) which enjoys the benefit of choosing whether
or not to exercise the option. The other side is the option writer.
|
|
Option
Strike Price
|
The price
at which the Option Holder can require option writer to deliver.
|
|
Exercise Lead Time
|
(Term) The Minimum Notification Duration expressed as an EMIX Term.
|
|
Option Exercise Schedule
|
(Term) The Availability Schedule
expressed as an EMIX Term.
|
|
Temporal Granularity
|
If present, expresses the temporal
granularity of requests as a Duration. For example, if the Duration is 15
Minutes, the option can be called at 10:00, 10:15, 10:30, or 10:45.
Granularity is a Property of the Option Schedule.
|
In TeMIX, very few terms are
used, and they are homogenous for the entire market. See 7 Standardizing Terms for Market Context for a discussion of exchanging market-wide
information.
The following comprise the
conformance rules for TeMIX:
1. All allowed TeMIX Product Elements are named in Tables
7-1, 7-2, 12-1 and 12-2.
2. For a given Market Context, all Product Elements MUST
be Defined in Standard Terms EXCEPT FOR
-
Starting Date and Time
-
Quantity
-
Price
-
Side
-
Tender Expiration Date and Time
3. All TeMIX Product Elements MUST BE UNDERSTOOD
4. All Elements NOT in the TeMIX Product Elements MUST BE
IGNORED
5. All TeMIX Intervals are transacted separately MUST NOT
have Links to other Intervals.
6. TeMIX MUST conform to all EMIX Conformance
Requirements
The allowed TeMIX Products
are:
·
TeMIX Power Product
·
TeMIX Transport Product
·
TeMIX Option Power Product
·
TeMIX Option Transport Product
The Transactive States for a
TeMIX are:
·
Indication of Interest (IOI)
·
Tender
·
Transaction
·
Delivery
·
Publish
The information model in this section is described in
RESOURCE.XSD
The Resource information model describes information that
MAY be used to offer product(s) in a market. The Resource model describes a
range of potential operational responses. The model allows parties to describe
a wide range operations, both generation and curtailment. Resource descriptions
are used tenders either to buy or tenders to sell Energy or Power products.
When making a tender for products and services, it is useful
to describe the operational characteristics 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.
Parties can potentially exchange these models, until they
come to an agreement. The rules for exchanging these models are outside the
scope of this specification. Resource tenders are less specific than a single
transactive request, and one Resource tender may be able offer the Resource to
more than one market.
Resources may represent a generator or a load responses or
aggregations. In interactions involving Resources it may be useful to describe
either (1) the proposed or actual operation of a Resources, or (2) the range of
capability of a Resource.
13.1
Resource Capabilities
The following curve characterizes the a schedule for
operation of a generic Resource
Figure 13‑1:Operational Profile of a Generic
Resource
In the Resource illustration above, there is some base level
of power, a status quo ante. When invoked, the resource takes a 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 the
information model in Power Resources is that generation, that is the production
of power, and load shedding, the reduction of power use are similar products.
Figure 13‑2: Equivalence of Load Shed and Generation
As shown in the example above, generation and load response
are similar and can be described using the same information model.
Many Resources have capabilities that change over the range
of response. A generator may have one ramp rate until it gets up to half speed,
and then another as it goes to full speed. Load response can have similar
characteristics. Such resources can be described by combining simple response
characteristics.
Figure
13‑3: Combining Resource Operational Responses
Resource capability descriptions describe what could be
done, as distinguished from a transaction in which specific performance is
requested or agreed to.
Resources capabilities may 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 ramps up at
Ramp 1 expressed in MW/minute. Between the Base 2 and Maximum 2, expressed in
MW, the resource can ramp up at Ramp 2 expressed in MW/minute.
Figure 13‑4: Ramp Rate Curve—CIM Style
As described in [IEC
62325-301], a
given resource may publish multiple ramp rate curves for different
circumstances. This resource capability description may be preferred to the
resource operation description in some interactions.
Assume the Resource is operated at the ramp rates as in Figure 13‑4 then an operation as described in Figure 13‑1. A capability
description is generally used to guide resource dispatch. Once the dispatch is
computed, an operational description can be used to tender or transact the
power that is the result of the dispatch from the market.
This specification describes market interactions, i.e., the
operational profiles. Only the description in Section 13.1 is in this
specification. When a single resource offers different ramp rates for different
circumstances, this specification considers the resulting operational profiles
to be distinct products.
The description in Section 13.2 may be considered at a later
date by the committee.
13.4
Resource Description Semantics
EMIX Resource Descriptions are an extension of the EMIX
Product Description. As an extension of the Product Description, resources can
be applied inside any EMIX schedule.
The only aspects of a Resource that matter 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.
Figure 13‑5: Resource Description base
The EMIX Resource Description base consists of the elements
shown in the table below.
Table 13‑1: Resource Description Elements
|
Resource Description Element
|
Note
|
|
MRID
|
The Master
Resource ID as defined in the [IEC TC57] IEC 61970-301.
|
|
EMIX
Interface
|
The
Interface is where the Resource injects or extracts power. Note: for many
transactions, reduced extraction is equivalent to injection.
|
|
Terms
|
In
addition to the Terms listed for Product performance, Resources have
additional Terms, listed in Table 10-2.
|
Power Resources descriptions can use any of the Terms or
requirements defined in EMIX. Power Resource descriptions can also use
additional Terms that are specific to Power:
Table 13‑2: Terms unique to Power Resources
|
Power Term
|
Note
|
|
Minimum
Load
|
Minimum
Load that a Resource can maintain.
|
|
Maximum
Power
|
Maximum
Power available from a resource.
|
|
Maximum
Energy
|
Maximum
Energy available from a resource.
|
|
Minimum
Load Reduction
|
Minimum
Load Reduction resource can make.
|
13.5
UML Summary of Resource Descriptions
Figure 13‑6: UML Summary of Resource Descriptions
The Generic Power Resource description is used both for
generation and for load Resources. The common Resource model is shown in the
following table.
Table 13‑3: Generic Power Response Resource
|
Generic Resource Element
|
Note
|
|
Staging
Ramp
|
An array of
Power Ramp Segments describing a Resource’s ability to change level at the
initiation of a Response.
|
|
Minimum
Response
|
The least
Response for which this resource will accept a request.
|
|
Maximum
Response
|
The
greatest Response for which this resource will accept a request.
|
|
Recovery
Ramp
|
An array
Power Ramp Segments describing how a Resource’s returns to its original state
following a response.
|
A Power Response Description MAY be accompanied by an Offer
Curve (described in section 13.6.2 Offer Curves). Each Ramp consists of zero to many Power Ramp Segments (see Figure 13‑3: Combining Resource Operational Responses).
13.6.1 Power Ramp Segments
Power Ramp Segments consist of the following elements shown
in the table below.
Table 13‑4: Power Ramp
|
Power Ramp Element
|
Note
|
|
Rate
|
Power
Units for the Ramp.
|
|
Begin
Ramp Quantiy
|
Power
Quantity at the beginning of the Segment.
|
|
End Ramp
Quantity
|
Power
Quantity at the end of the Segment.
|
|
Duration
|
The time
between the begin ramp and the end ramp.
|
|
Integral
Only
|
If true,
one can’t stop between the begin and end rates.
|
While Power Ramps are generic, specific instances within
derived Resource Descriptions are subject to different conformance rules.
For a Generation Resource, Staging Ramps are processed in
order of increasing End Power. The quantity of End Power MUST be greater than
the quantity of the Begin Power for each Ramp in the Staging Ramp. Recovery
Ramps are processed in order of decreasing End Power. The quantity of End Power
MUST be less than the quantity of Begin Power for each Ramp in the Recovery
Ramp.
For a Load Resource, Staging Ramps are processed in order of
decreasing End Power. The quantity of End Power MUST be less than the quantity
of Begin Power for each Ramp in the Staging Ramp. Recovery Ramps are processed
in order of increasing End Power. The quantity of End Power MUST be greater
than the quantity of the Begin Power for each Ramp in the Recovery Ramp.
Load Resources and Power Resources are conformed instances
of the Generic Power Resource.
13.6.2 Offer Curves
When the capability of Power Resource tendered, it may be
accompanied by an Offer Curve. An Offer Curve is comprised of a number of Offer
Segments. An Offer Segment defines the offer price (as expressed in EMIX
Requirements) for the quantity offered in each segment. A sequence number
indicates the order of the segments. Each segment may be offered in any partial
amount or all-or-none.
Table 13‑5: Resource Offer Segment
|
Resource
Offer Element
|
Note
|
|
Price
|
Energy
Price for this Segment.
|
|
Quantity
|
Power
Quantity for this Segment.
|
|
Duration
|
Duration
of the Segments.
|
|
Units
|
Power Units
in which Segment is denominated.
|
|
Units
|
Energy
Units in which Segment is denominated.
|
|
Integral Only
|
If true,
offer is all or none; no partial acceptance of this segment.
|
13.7
Voltage Regulation Resources
Voltage regulation services
have their own particular semantics as described in the following table.
Table 13‑6: Semantics for Voltage Regulation
Services
|
Voltage Regulation Element
|
Note
|
|
VMin
|
VMin is
the minimum voltage level of 88% of nominal voltage where the photovoltaic
(PV) inverter must disconnect, as defined in [IEE1547].
|
|
VMax
|
VMax is
maximum voltage level of 110% of nominal voltage where the photovoltaic (PV)
inverter must disconnect, as defined in [IEE1547].
|
|
QMax
|
QMax is the inverter’s present reactive power (VAR)
capability and may be positive (capacitive) or negative (inductive). It can
also be considered as the apparent power (VA) capability left after
supporting the real power (W) demand. See [Budeanu] and [IEEEv15#3].
|
14 Ancillary Services Products
Ancillary Services are defined in the schema
POWER-PRODUCTS.XSD
Ancillary Services are typically products provided by a
Resource contracted to stand by for a request to deliver changes in power to
balance the grid on short notice. Ancillary services include Regulation, Spinning
Reserve, Non-Spinning Reserve and Volt/Var support (Reactive Power). Resources
providing Ancillary services may be paid for availability, whether or not they
are dispatched. Of course, if dispatched, they are obligated to perform. Demand
side Resources, when qualified, may provide Ancillary Services
Figure 14‑1: UML Ancillary Services Product
The Ancillary Services Type is derived from the abstract
Emix Option base type. Ancillary Services are described using the market
semantics of Options within the EMIX Option type. Performance expectations are
expressed using Terms. Strike prices and the penalty for non-performance are
part of the option agreement.
Because it is useful to have a short-hand to refer to these
services, they are enumerated in the Power Option Type enumeration which is
incorporated into the Power Product Types. The enumerated Power Option Types
are:
·
Operating Reserve
·
Regulation Service Up
·
Regulation Service Down
·
Regulation Service Up/Down
·
Synchronized Reserve
·
Non-Synchronized Reserve
·
Black Start Recovery
·
Reactive Power
The enumerated list is extensible as described in Appendix
B.1: “Extensibility in Enumerated Values”. Because the exact definitions vary
from market to market, and will continue to vary over time, EMIX does not
define these terms. All definitions and performance requirements SHALL be
expressed through the Terms.
The information model in this section is described in
EMIX-WARRANTS.XSD
Warrants are specific assertions about the extrinsic
characteristics of EMIX Products that may affect market pricing. Warrants are
"a written assurances that some product or service will be provided or
will meet certain specifications."
Parties may use warrants to exchange information about the
source of the energy or about its environmental characteristics. Sellers may
use EMIX Warrants to provide information about the source of the energy or
about its environmental characteristics. Buyers may use warrants to indicate
what they wish to purchase. EMIX does not define specific warrants, although it
does define base types for extension by those who wish to develop the various
types of warrants.
The general form of a warrant is similar to that of an EMIX
Product. It can vary by time, using schedules as in WS-Calendar. The Intervals
in a Warrant may differ from those of the Product on the outside of the
envelope. There may be zero Intervals in a Product if the unchanged product
description applies to all.
Some Warrants may be separable from the underlying energy.
For example, a Warrant that energy is generated by a source that is certified
as "green" by an authority, may be issued a "green
certificate". In some markets, such a certificate can be traded
separately.
Today, the information conveyed in warrants is local, and
not ready for standardization. For example, in 2011 energy warranted as
renewable in the Pacific Northwest can include hydropower. Energy markets in
California exclude hydropower from their definition of renewable power. Credits
or mandates for renewable energy in California are not met by Products
warranted as renewable in the Pacific Northwest.
The Technical Committee has chosen to define a general
semantic mechanism to convey warrants, without standardizing warrants in v1.0.
The Technical Committee defined broad classes of warrants, any of which may be
the subject of a future standardization effort.
Parties that need additional types of warrants can extend
the abstract Warrant Type to create a new base type for Warrants not defined in
this specification.
Figure 15‑1: UML Summary of Warrants
15.1
Warrants Described
Warrant Types are abstract types defined in this
specification for extension and definition elsewhere. Conforming information
exchanges can include schema types derived from these types.
Table 15‑1: Warrant Types
|
Warrant Type
|
Descriptions
|
|
Product
Quality
|
A Quality
Warrant asserts or requires that the product be of a certain quality or
better. A quality warrant includes an array of Quality Measures. The Quality
Measure type is extensible to support the definition of additional quality
measures.
|
|
Environmental
Warrant
|
An
Environmental Warrant is used to assert what environmental effects of the
product. These may include emission of a chemical, or use of a scarce
resource. No environmental warrants are defined in the EMIX v1.0. Parties
wishing to exchange Environmental Warrants may extend this type to create the
environmental assertions that they require.
|
|
Source
Warrant
|
A Source
Warrant consists of assertions the sources (often meaning the technologies)
of the commodity included in this product. Source often has specific
regulated meaning in different jurisdictions, so no definition of Source is
included in this specification. Parties that require Source information may
extend this type to create the source assertions that they require.
|
|
Support
for Price
|
Support
for Price conveys additional information to support the price on the outside
of the envelope. It was originally conceived of as a potential array of
products with their own prices. An example is the wholesale purchase of a
product, along with transport products to establish a base cost to support a
contracted price. Without further definition, support for price is not
restricted in this way as of v1.0, and Parties that wish to exchange price
support may extend this type to meet their needs.
|
The information model in this section is described in
POWER-QUALITY.XSD.
Higher quality power can obtain a market premium. A buyer
willing to accept lower quality power may be able to obtain it at lower
expense. Power qualities must be measurable, discrete, and allow buyers and
sellers to make choices. They must also be auditable and measurable by a
specific defined protocol, so performance can be compared to promise.
Figure 16‑1: UML of Power Quality Warrant
16.1
Power Quality Warrant
There are numerous protocols for determining power quantity,
and often more than one name for the same quality. Assertions about Power
Quality must be qualified with what protocol is being used, and must be able to
specify the period or periods to which they refer.
The Power Quality Warrant is similar to the EMIX Base. As an
extension to the EMIX Base, it holds a schedule, which can be populated with
Quality Assertions. A Quality Assertion is a collection of Quality Statements
that apply for an Interval.
Table 16‑1: Elements of the Power Quality
Warrant
|
Product Element
|
Description
|
|
Quality
Warrant
|
See Table 15‑1: Warrant Types
|
|
Power
Quality Type
|
An enumerated string that about the origins of the
Warrant. Defined enumerations are Guaranteed, Measured, Projected, Average.
|
|
Measurement
Protocol
|
A string containing an identification of the standard or
other protocol used to measure power quality.
|
|
Schedule
|
Sequence populated by a Quality Measure (Table 16‑3)
|
|
Side
|
Buy or Sell, as defined in Table 3‑5: Simple Semantic Elements of EMIX. Side can be used to determine whether this warrant is a
requirement or a promise.
|
|
Quality
Measure
|
Quality Measure is a collection of Power Quality
Indicators (Table 16‑3) Note: Quality Measure can be applied EITHER in
the intervals of the schedule in emixBase inherited from the
emix:QualityWarrant OR in external to the Intervals, but not both.
|
The Schedule is populated by Quality Measures. A Quality
Measure is a collection of Power Quality Indicators. The Power Quality
indicators MUST be recorded as per the requirements and definitions in the
Measurement Protocol. The defined Power Quality indicators are in Table 16‑3: Power Quality Indicators.
The terminology for characteristics is largely that of [IEC61000-4-30]
and the generally similar [Caramia]. Table 16-2 defines strings for
Measurement Protocol in Table 15-3; others may be added by prefixing “x-“ as
described in Appendix B “Extensibility in EMIX”.
Table 16‑2: Named Power Quality Protocols
|
Protocol
|
Reference
|
|
EN
50160
|
As described in [EN50160]
|
|
IEEE 1519-2008
|
As described in [IEEE1519
|
|
IEC 61000-2003
|
A described in [IEC61000-2003]
|
The power quality indicators are described in Table 16‑3. Other Quality Indicators can be defined by deriving from the base
Quality Indicator type.
Table 16‑3: Power Quality Indicators
|
Name
|
Description
|
|
Measurement
Protocol
|
A string
containing an identification of the standard or other protocol used to
measure power quality.
|
|
Power
Frequency
|
A floating
point number describing the measured Power Frequency. Note: users who wish to
describe how the frequency varies over time will need to derive their own
measure from the base Power Quality type.
|
|
Supply
Voltage Variations
|
An
unsigned integer count of Supply Voltage Variations during the period.
|
|
Rapid
Voltage Changes
|
An
unsigned integer count of Rapid Voltage Change events during the period.
|
|
Flicker
ST
|
A
measurement of Short Term Rapid Voltage Change. The actual periods for
measurement are defined in the measurement protocol documents.
|
|
Flicker
LT
|
A
measurement of Long Term Rapid Voltage Change. The actual periods for
measurement are defined in the measurement protocol documents..
|
|
Supply
Voltage Dips
|
An
unsigned integer count of Supply Voltage Dip events (called Sags in some
protocols) during the period.
|
|
Short
Interruptions
|
An
unsigned integer count of Short Interruption events during the period.
|
|
Long
Interruptions
|
An
unsigned integer count of Long Interruption events during the period.
|
|
Temp
Overvoltage
|
An unsigned
integer count of Temporary Overvoltage events during the period.
|
|
Supply
Voltage Imbalance
|
An
unsigned integer count of Supply Voltage Imbalance events during the period.
Not meaningful for DC.
|
|
Harmonic
Voltage
|
A floating
point number for the Harmonic Voltage during the period. For DC, distortion
is with respect to a signal of zero (0) Hz.
|
|
Mains
Voltage
|
A floating
point number indicating Mains Voltage.
|
|
Mains
Signaling Voltage
|
A floating
point number indicating Mains Signaling Voltage, relating generally to power
line communications systems.
|
Figure 16‑2: UML Summary of Power Quality Indicators
17
Conformance and Rules for EMIX and Referencing Specifications
This section specifies conformance related to the semantic
model of EMIX. EMIX is heavily dependent upon [WS-Calendar], and
repeatedly incorporates [WS-Calendar]-based information models.
EMIX Artifacts can be exchanged at any of several stages of
a transaction. Necessarily, a tender must be able to accept an incomplete
information model while a call for execution must fully define the performance
expected. Specifications referencing EMIX SHALL define conformance rules by
transaction type and market context.
EMIX conformance necessarily occurs in two stages. EMIX uses
[WS-Calendar] to communicate similar Intervals that occur over time,
each containing an EMIX Artifact. Portions of that Artifact may be expressed
within the Lineage of the sequence. Applications MUST apply [WS-Calendar]
Inheritance and then EMIX Inheritance to Compose the information exchange for
each Interval. Only after Composition, can the EMIX Artifact within each
Interval of the Sequence be evaluated for conformance and completeness.
17.1 EMIX Conformance with [WS-Calendar]
EMIX Base are EMIX Products and Resources instantiated
through the schedule model of [WS-Calendar]. As such, EMIX Base SHALL
follow [WS-Calendar] Conformance rules. These rules include the
following conformance types:
- Conformance
to the inheritance rules in [WS-Calendar], including
the direction of inheritance
- Specific
attributes for each type that MUST or MUST NOT be inherited.
- Conformance
rules that Referencing Specifications MUST follow
- Description
of Covarying attributes with respect to the Reference
Specification
- Semantic
Conformance for the information within the Artifacts exchanged.
EMIX Products and Resources also extend the Inheritance
patterns of [WS-Calendar] to include the EMIX information model. We
address each of these in the following sections.
17.1.1 Inheritance
in EMIX Base
The rules that define
inheritance, including direction in [WS-Calendar], are recapitulated.
I1: Proximity Rule Within
a given lineage, inheritance is evaluated though each Parent to the Child
before what the Child bequeaths is evaluated.
I2: Direction Rule
Intervals MAY inherit attributes from the nearest Gluon subject to the
Proximity Rule and Override Rule, provided those attributes are defined as
Inheritable.
I3: Override Rule If and
only if there is no value for a given attribute of a Gluon or Interval, that
Gluon or Interval SHALL inherit the value for that attribute from its nearest
Ancestor in conformance to the Proximity Rule.
I4: Comparison Rule Two
Sequences are equivalent if a comparison of the respective Intervals succeeds
as if each Sequence were fully Bound and redundant Gluons are removed.
I5: Designated Interval
Inheritance [To facilitate composition of Sequences] the Designated
Interval in the ultimate Ancestor of a Gluon is the Designated Interval of the
composed Sequence. Special conformance rules for Designated Intervals apply
only to the Interval linked from the Designator Gluon.
I6: Start Time Inheritance
When a start time is specified through inheritance, that start time is inherited
only by the Designated Interval; the start time of all other Intervals are
computed through the durations and temporal; relationships within the Sequence.
The designated Interval is the Interval whose parent is at the end of the
lineage.
17.1.2 Specific Attribute Inheritance
within EMIX Envelopes
This section refers to EMIX Products, agreements, and
Resources as Artifacts. In general, an Artifact of a particular type blocks
inheritance of a complete Artifact of that type down the lineage.
The root node of parent and the child must match for blended
inheritance to occur, that is, the roots must be of the same type. The
exception is if there are no roots in the child’s Artifact, then the root and
all its branches are inherited by the child.
If matching roots for the model are found in both the parent
and in the child, then each tree should be navigated to determine blended
inheritance. The child’s artifact may be mostly unpopulated. Within any branch
in the child, the first node that is populated blocks all further inheritance
on that branch. All nodes deeper into the Artifact than that populated node are
determined by the child. When a branch is inherited from the child, it blocks
the inheritance of any deeper nodes within that branch.
Specific artifacts may declare rules that break this
inheritance pattern. As of now, the exceptions are:
- There
are no exceptions.
Inheritance creates a virtual artifact at each level of
processing. That virtual Artifact is the basis for inheritance for any child
Artifact.
In EMIX the following attributes MUST NOT be inherited
- UID
(Gluons and Intervals)
- Temporal
Relationships
Some elements of EMIX are may be
covariant, meaning that they change together. Such elements are treated
as a single element for inheritance, they either are inherited together or the
child keeps its current values intact. This becomes important if one or more of
a covariant set have default values. In that case, if any are present, then
inheritance should deem they are all present, albeit some perhaps in their default
values.
The time zone MUST be explicitly
expressed in any conforming EMIX Artifact.
This may be accomplished in two
ways:
·
The time, date, or date and time MUST be specified using [ISO8601]
utc-time (also called zulu time)
·
The [WS-Calendar] Time Zone Identifier, TZID, MUST be in
the Lineage of the artifact, as extended by the Standard Terms. See 17.3 below.
If neither expression is included, the Artifact does not
conform to this specification and its attempted use in information exchanges
MUST result in an error condition.
If an Artifact exists within the context of Standard Terms,
the artifact inherits from the Standard Terms. Elements that can be inherited
from Standard Terms include Product Type, TZID, Currency, and Measurement
Units.
Inheritance MUST be determined in the manner of Section 17.1.1. Rules I1, I2, and I3, that is, that the attribute definition be determined by
going to the nearest Gluon in the Lineage containing that attribute, with the
addition that if no such Gluon is present then the search continues in the
associated Standard Terms.
1. If the
Designated Interval in a Series has a Price only, all Intervals in the Sequence
have a Price only and there is no Price in the Product.
2. If the
Designated Interval in a Series has a Quantity only, all Intervals in the
Sequence have a Quantity only and there is no quantity in the Product.
3. If the Designated
Interval in a Series has a Price & Quantity, all Intervals in the Sequence
MUST have a Price and Quantity and there is neither Price not Quantity in the
Product.
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.
Carl Besaw, Southern California Edison (SCE)
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 Laundergan, Southern California Edison (SCE)
Alex Levinson, Lockheed Martin*
Dirk Mahling, CPower
Scott Neumann, Utility Integration Solutions Inc.
Robert Old, Siemens AG
John Petze, Individual
Joshua Phillips, ISO/RTO Council (IRC)
Donna Pratt, ISO/RTO Council (IRC)
Ruchi Rajasekhar, Midwest Independent Transmission System
Operator, Inc.
Carl Reed, Open Geospatial Consortium, Inc. (OGC)*
Jeremy Roberts, LonMark International*
Anno Scholten, Individual
Aaron F. Snyder, Enernex
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)
Extensibility was a critical design
constraint for EMIX. Extensibility allows the EMIX specification to be used in
markets and in interactions that were not represented on the Technical
Committee. Formal extensibility rules also create a set of complaint extensions
for incorporation into later versions that are already compliant.
B.1 Extensibility in Enumerated values
EMIX defines a number of enumerations. Some of these, such
as measurements of power, are predictably stable. Others, such as market
contracts or energy sources, may well have new elements added. In general,
these accept any string beginning with “x-“ as a legal extension. In
particular, these are defined using the following mechanism in the formal
schemas (XSD’s).
In emix.xsd, the extensibility pattern is:
<xs:simpleType
name="EMIXExtensionType">
<xs:annotation>
<xs:documentation>Pattern
used for extending string enumeration, where allowed</xs:documentation>
</xs:annotation>
<xs:restriction
base="xs:string">
<xs:pattern
value="x-\S.*"/>
</xs:restriction>
</xs:simpleType>
An example of non-extensible enumerated types is:
<xs:simpleType
name="PowerOptionTypeEnumeratedType">
<xs:annotation>
<xs:documentation>Power
Reserve Options</xs:documentation>
</xs:annotation>
<xs:restriction
base="xs:string">
<xs:enumeration
value="SpinningReserve"/>
<xs:enumeration
value="NonSpinningReserve"/>
<xs:enumeration
value="OperatingReserve"/>
<xs:enumeration
value="DemandResponse"/>
</xs:restriction>
</xs:simpleType>
The enumerations used in the specification follow this
pattern:.
<xs:element
name="powerOptionType"
type="power:PowerOptionTypeType"/>
<xs:simpleType
name="PowerOptionTypeType">
<xs:union
memberTypes="power:PowerOptionTypeEnumeratedType emix:EmixExtensionType"/>
</xs:simpleType>
This pattern has been followed throughout EMIX, allowing any
string beginning “x-“ to be a legal extension enumeration for EMIX enumerated
strings.
Some extensible enumerated types assume they will be used
for extension. For example, the means of measurements for power quality
enumerate specific testing protocols. As of this writing, there are only two
testing protocols in the specification.
<xs:simpleType
name="MeasurementProtocolEnumeratedType">
<xs:restriction
base="xs:string">
<xs:enumeration
value="EN 50160"/>
<xs:enumeration
value="IEEE 1549-2009"/>
</xs:restriction>
</xs:simpleType>
It is anticipated that other protocols will be used. In this
case the suffix "EnumeratedType"is used to allow for the possibility
of other Measurement Protocols that are not enumerated. Actual compliance,
though, is based upon the type:
<xs:simpleType
name="MeasurementProtocolType">
<xs:union
memberTypes="power:MeasurementProtocolEnumeratedType
emix:EMIXExtensionType"/>
</xs:simpleType>
That is, valid values for the measurement protocol are the
enumerated values, and any that match the extension pattern “x-*”
EMIX defines extensibility for the following values:
- [Quality]
Measurement Protocol
- Contract
Type
- Option
Type
- Power
Option Type
- Resource
Type
B.2 Extension of Structured Information Collective Items
EMIX anticipates adding some information structures that are
more complex than simple strings that can also be extended. A challenge for
these items is that they are more complicated and so require formal definition.
Formal definitions, expressed as additions to schema, could require changes to
the specification. Without formal definition, it is difficult for trading
partners to agree on valid information exchanges.
EMIX uses abstract classes for many information exchanges.
For example, trading partners could agree on the exchange of larger or smaller
lists of quality measures. Many measures of power quality are defined in
power-quality.xsd. Quality consists of an array of elements that are derived
from the abstract base quality element.
<xs:complexType
name="PowerQualityType">
<xs:annotation>
<xs:documentation>Power
Quality consists of a number of measures, based on contract, negotiation, and
local regulation. Extend Power Quality to incorporate new elements by creating
additional elements based on PowerQualityBaseType</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element
name="measurementProtocol"
type="power:MeasurementProtocolType"/>
<xs:element
name="constraints" type="power:ArrayOfPowerQualities"/>
</xs:sequence>
</xs:complexType>
A practitioner who wanted to add an additional quality type
would need to develop a description and instantiation of that type based on the
abstract base, similar to that used below. The implementation refers to the
substitution group:
<xs:element
name="supplyVoltageVariations"
type="power:SupplyVoltageVariationsType"
substitutionGroup="power:basePowerQualityMeasurement"/>
and the type extends the abstract base class
BasePowerQualityMeaurementType:
<xs:complexType
name="SupplyVoltageVariationsType" mixed="false">
<xs:complexContent
mixed="false">
<xs:extension
base="power:BasePowerQualityMeasurementType">
<xs:sequence>
<xs:element
name="count" type="xs:int"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
The resulting schema, which references the approved EMIX
schemas, but does not change them, can then be distributed to business partners
to validate the resulting information exchanges. The core EMIX types, which are
used throughout the specifications herein, can be extended this way, including:
- EMIX
Base Type: iCalendar-derived object to host EMIX Product Descriptions
- Product
Description Type: In EMIX, the Product Description is the basis for all
Resources and Product Descriptions.
- Item
Base: Abstract base class for units for EMIX Product delivery, measurement,
and Warrants. Item does not include Quantity or Price, because a single product
description or transaction may have multiple quantities or prices associated
with a single item.
- EMIX
Interface: Abstract base class for the interfaces for EMIX Product
delivery, measurement, and/or pricing.
The following additional abstract types are among those
designed with extension by practitioners in mind:
- BasePowerQualityMeaurementType:
the basis for exchanging measurements of power quality
- BaseTermType:
used to express Terms on the performance of equipment exposed to the market as
Resources
- BaseRequirementType:
used to express the market or business requirements of a trading partner.
- BaseWarrantType:
the root for all Warrants delivered with the energy product.
C. Electrical
Power and Energy
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 envelope
contents, perhaps as informational support for the intrinsic prices.
To put the terms "Power" and "Energy"
into the proper context for this specification, the following definitions will
be used:
• Apparent
Energy: the production or consumption of Apparent Power over time; unit: volt-ampere
hours; abbreviation: VAh
• Apparent
Power (S): mathematical product of root-mean-square voltage and
root-mean-square current, vector sum of Real Power and Reactive Power, square
root of sum of squares of Real Power and Reactive Power; unit: volt-ampere;
abbreviation: VA
• Current:
flow of electric charge, or rate of flow of electric charge; unit: ampere;
abbreviation: A
• Energy:
the production or consumption of Power over time.
• Power
Factor: ratio of Real Power to Complex Power, cosine of the phase angle between
Current and Voltage, expressed as a number between 0 and 1, expressed as a
percentage (i.e., 50% = 0.5); unit: dimensionless; abbreviation: p.f.
• Power
Triangle: the mathematic relationship between the Apparent Power (S), the Real
Power (P) and the Reactive Power (Q) where S = sqrt(P*P + Q*Q).
• Reactive
Energy: the production or consumption of Reactive Power over time; unit:
volt-ampere-reactive hours; abbreviations: VARh, VArh, VA-rh, varh
• Reactive
Power (Q): mathematical product of the root-mean-square voltage and
root-mean-square current multiplied by the sine of the angle between the
voltage and current; unit: volt-amperes reactive; abbreviations: VAR, VAr,
VA-r, var
• Real
Energy: the production or consumption of Real Power over time; unit: Watt-hour;
abbreviation: Wh
• Real
Power (P): rate at which electricity is produced or consumed, mathematical
product of Voltage and Current; unit: Watt; abbreviation: W
• Voltage:
difference in electric potential between two points; unit: volt, abbreviation:
V
Generically,
the use of the term "Power" refers to "Real Power" and is
expressed in Watts. Otherwise, one talks of Apparent Power in VA, or Reactive
Power in VARs. Generically, the use of the term "Energy" refers to
"Real Energy" and is expressed in Watt-hours. Otherwise, one talks of
Apparent Energy in VArh, or Reactive Energy in VArh.
Energy Interoperation can be used in today’s markets and
business interactions. Generally accepted business terms for these markets were
defined for both the retail and wholesale electrical quadrants in the [NAESB
PAP03].
Because Energy Interoperation describes a general-purpose
mechanism that can be used by parties for today’s market interactions at
several levels of today’s markets as well as for new and extended future
interactions, the terms do not determinatively map to the NAESB semantics.
Symmetric use of the interfaces in this specification can make some mappings
ambiguous.
There are several kinds of definitions used in Energy
Interoperation and in EMIX.
(1) Abstraction over a
class of similar information (for example, the EMIX Interface, the EmixInterfaceType
abstract type, addresses all locational information including geospatial,
P-Node, AP-Node, and more.)
(2) Simplification
(for example, Party addresses all Business Entities as the focus is on the
service interaction; a Business Entity presents and assumes various roles and
interfaces)
(3) Algebraic combination
(for example, a Resource summarizes characteristics from both curtailment and
generation/battery draw-down as equivalent, though the market values and
markets may vary)
Some terms are outside the scope of Energy Interoperation,
hence neither used nor defined (for example, Asset, Resource Object,
Regulator).
With these caveats, most of the terms defined by NAESB can
be mapped to those in this specification.
NOTE: Market Participant is not defined explicitly; Party is
the generalization of business entities. A Party enrolls and some of the
“things enrolled and is qualified in” are roles such as LSE, MA, etc…so the
answer for those is “Party enrolled as …”
|
NAESB Term
|
Definition
from NAESB
|
Energy
Interoperation Term
|
|
Asset
|
A logical entity with measurable and reportable
consumption, e.g. an Asset may be a physical device with its own meter, or
the main meter at the Service Delivery Point of a Service Location.
|
Not used in 1.0
|
|
Asset
Group
|
A logical entity that has a reportable interval level
consumption, e.g. an Asset Group may be a physical entity with its own meter,
a neighborhood of homes that has a net meter, or an estimate of consumption
of an aggregation of retail customers.
|
Not used in 1.0
|
|
Business
Entity
|
The
wholesale or retail entity that interacts with other entities in its market.
|
Party
|
|
Communication
Method
|
The method by which an object communicates with
another object to instruct, measure, report or control.
|
Out of scope. Energy Interoperation defines SOA Web
Services
|
|
Control
|
The
role associated with the control of an end device.
|
Out
of scope
|
|
Designated
Dispatch Entity (DDE)
|
A role which carries the responsibility of receiving
and processing demand resource dispatch instructions or market information
and (optionally) providing response information.
|
Party enrolled as DDE
|
|
Distributed
Energy Resources (DER)
|
|
|
|
Environmental
Authority (EA)
|
A regulatory authority responsible for the
development, reporting and enforcement of environmental activities.
|
Out
of scope
|
|
Federal
Regulator (FR)
|
A
federal regulatory authority.
|
Out
of scope
|
|
Load-Serving
Entity (LSE)
|
The
responsible entity that secures energy and Transmission Service (and related
Interconnected Operations Services) to serve the electrical demand and energy
requirements of its end-use customers.
|
Party
enrolled
as LSE
|
|
Local
Authority (LA)
|
A regulatory authority responsible for the oversight
and administration of utility service-related functions within its
jurisdiction.
|
Out of scope
|
|
Market
Enrollment
|
The collection of enrollment or tariff data for a Resource
Object to provide a specific market product or service.
|
Enrollment of a Resource combined with Market
Standard Terms
|
|
Market
Participant (MP)
|
An
organization registered with the System Operator that may take on roles such
as SP, LSE, TDSP, DDE, SE, and/or MA in accordance with the SO’s market
rules.
|
Party enrolled as an MP
|
|
Measurement
|
The
role associated with the device or algorithm that measures the consumption or
supply of an end device.
|
Measurement
|
|
Meter
Authority (MA)
|
A role which carries the responsibility of providing
data necessary to determine the performance of a Resource.
|
Party enrolled as an MA
|
|
P-Node
|
The price location of the Premise in the transmission
and/or distribution network.
|
EMIX Interface is superclass
|
|
Participant
|
The entity that represents resources to a market or
distribution operator.
|
Party
|
|
Regulator
|
A
rule-making and enforcement entity.
|
Out
of scope
|
|
Resource
|
A market-dependent group of Response Method
Aggregations that represents a dispatchable entity.
|
EMIX Resource
|
|
Resource
Object
|
Physical
and logical types of demand response resource objects.
|
Out
of scope
|
|
Scheduling
Entity(SE)
|
A role which carries the responsibility of submitting
bids/offers and receives schedules and awards.
|
Party enrolled an SE
|
|
Service
Delivery Point
|
The
identifier of the location where electric service is delivered to the Service
Location.
|
EMIX
Interface
is superclass
|
|
Service
Location
|
The physical location at which connection to the
transmission or distribution system is made.
|
EMIX Interface is superclass
|
|
Service
Provider (SP)
|
A role which carries the responsibility of
coordinating resources to deliver electricity products and services to a
market or distribution operator.
|
Party enrolled as an SP.
All roles offer services.
|
|
State
Regulator (SR)
|
A
regulatory authority responsible for the oversight and administration of
electric utilities.
|
Out
of scope
|
|
Supporting
Objects
|
Objects that support the interaction of Business
Entities and Resource Objects.
|
Out of scope
|
|
Transmission/Distribution
Service Provider (TDSP)
|
A role which carries the responsibility of operating a
local electricity transmission and/or distribution system.
|
Party enrolled as a TDSP
|
|
Utility
Customer (UC)
|
An end-use customer of the Utility Distribution
Operator that takes on roles such as Premise or Resource.
|
Not defined explicitly. Party may take role
|
|
Utility
Distribution Operator (UDO)
|
An entity which carries the responsibility of
operating an electricity distribution system.
|
Not defined explicitly. Party that provides
transport products
|
|
Zone
|
A
physical or electrical region.
|
EMIX
Interface
is the superclass
|
|
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
Ed Cazalet
Dave Holmberg
|
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
Ed Cazalet
|
Changes to resources, block
power, misc. tightening of document
|
|
WD15
|
2010-11-14
|
Toby Considine
Ed Cazalet
Sean Crimmins
|
EMIX Sequence changed to EMIX
Base. General tightening. Addition of Load and Power Offers, including 3-part
bids for each.
|
|
CSD01
|
2010-11-15
|
Toby Considine
|
Minor changes as per comments
|
|
WD16
|
2011-01-15
|
Toby Considine
|
46 Minor issues from PR01
Adopted new WD format
Moved namespaces into section 1
Adjusted duplicate table names
Fixed section numbering
anomalies
|
|
WD17
|
2011-02-08
|
Toby Considine
|
Issue Resolution. See Release
Notes from Jira
|
|
WD18
|
2011-03-07
|
Toby Considine
|
Numerous Jira Issues, (see
release notes), Significant Schema work: Resources as discussed, General EMIX
constraints and requirements now in Core EMIX namespace, but isolated in
requirements.xsd. Added schedule constraints as optional constraint
|
|
WD19
|
2011-03-17
|
Toby Considine
|
Tightened language, some
egregious errors and references not found removed
|
|
WD20
|
2011-03022
|
Toby Considine
|
Simplified Tables, Added NAESB
appendix, updated schemas in appendix
|
|
WD21
|
2011-0323
|
Toby Considine
|
Quick Pass for show-stoppers,
Purged last 16 uses of EMIX Terms for EMIX Base,
|
|
WD22
|
2011-0329
|
Toby Considine
|
Minor edits and comments from
Jira. Made explicit relations between Base, Product Description, Items,
Interfaces, and all derived extensions
|
|
WD23
|
2011-0411
|
Toby Considine
|
Extensive review and re-write to consolidate changes as
logged in Jira
|
|
WD24
|
2011-05-29
|
Anne Hendry
|
Reorganization, underbrush of PR02
|
|
WD25
|
2011-05-31
|
Toby Considine
|
Paul Knight comments, related
|
|
WD26
|
2011-06-01
|
Toby Considine
|
Most Aclara comments, Gerry Gray comments, Cox comments,
others from Jira
|
|
WD27
|
2011-06-05
|
Anne Hendry
Dave Holmberg
Ed Cazalet
Toby Considine
|
Tightened spec, formalized many definitions earlier,
incorporated many suggestions for improving definitions, moved base class,
non-normative ref to WS-Calendar to Section 2, Changes made up only though
Section 5 (6 and 7 may require complete re-write)
|
|
WD28
|
2011-06-07
|
Toby Considine
|
Completed run though from WD27
Added Market Rules section
|
|
WD29
|
2011-06-14
|
Toby Considine
|
Jira issues from PR02
Added Plenty-O-UML
Propagated Envelope language
Removed top level TEMIX Base type
Moved Temix toward Profile
|
|
WD30
|
2011-06-15
|
Toby Considine, Aaron Snyder
|
Too numerous to list here, almost 100% editorial.
|
|
WD31
|
2011-06019
|
Toby Considine
|
Many Editorial issues, Updates to Resource Introduction,
TeMIX, Offer Curves
|
|
WD32
|
20110620
|
Toby Considine
|
Editorial final pass, esp Offer Segments
|
|
WD33
|
2011-06-21
|
Toby Considine
|
More editorial, moves some references to non-normative
*Integral Only* in Product and Option
|
|
WD34
|
2011-06-22
|
Toby Considine
|
Minor changes (Josh Phillips in Jira) in intro material in
sections 2, 4, 13
|
|
WD35
|
2011-06025
|
Toby Considine
|
Minor changes made in meeting – not separately logged
|
|
WD36
|
2011-0905
|
Ed Cazalet
Aaron Snyder
Toby Considine
|
Changes as per separate document on Changes to WD36.
Responsive to comments following public review
|
|
WD37
|
2011-0906
|
Toby Considine
|
Updated NAESB Appendix (Cox).
Updated Ancillary Services Section
Cleaner language on Warrants
Misc speeling & math errors
Updated UML throughout document
|
