Retail Block and Tier Prices Using EMIX Version 1.0

This Note describes how an application using the EMIX information model can receive Full Requirements Block & Tier Tariffs, (which we abbreviate Block & Tier) and describes how the information can be used by any model rich enough to encompass this sort of price information.

Status:

This document was last revised or approved by the OASIS Energy Market Information Exchange (eMIX) TC on the above date. The level of approval is also listed above. Check the “Latest version” location noted above for possible later revisions of this document.

Technical Committee members should send comments on this document to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at http://www.oasis-open.org/committees/emix/.

Citation format:

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

[emix-block-v1.0]

Retail Block and Tier Prices Using EMIX Version 1.0. 07 December 2012. OASIS Committee Note 01. http://docs.oasis-open.org/emix/emix-block/v1.0/cn01/emix-block-v1.0-cn01.html.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

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

Table of Contents

1 Introduction. 4

1.1 References. 4

1.1.1 OASIS Committee Specifications and Drafts. 4

1.1.2 Other References. 4

2 Block & Tier Prices. 5

2.1 Description of the Problem.. 5

2.2 Information Exchange. 5

2.3 Scoping of the Problem.. 6

3 Information Structure for Block & Tier. 8

3.1 EMIX Information Structure. 8

3.2 SEP 2.0 Information Structure. 8

3.3 Comparison of EMIX and SEP 2.0 Information Structures. 9

4 Summary and Conclusions. 11

Appendix A. Acknowledgments. 12

Appendix B. Revision History. 13

1 Introduction

This Note describes how an application using the EMIX information model can receive Full Requirements Block & Tier Tariffs, (which we abbreviate Block & Tier) and describes how that information can be used by any model rich enough to encompass this sort of price information.

We describe the information for price inflection points, and then how that information is expressed in EMIX 1.0 Public Review 04. In addition we show how the same information is expressed in Smart Energy Profile 2 [SEP2], which has a rich price information model.

In EMIX information can be combined for a rich expression of anything from price and product applied to a single interval to complex schedules over extended periods of time, with or without gaps.

Any application that can express Full Requirements Block & Tier Tariff information can use that application’s mapping to build a mapping from EMIX to its environment; if the artifacts are expressed in XML in that application environment then an XSLT transformation may be created.

1.1 References

1.1.1 OASIS Committee Specifications and Drafts

[EMIX]

Energy Market Information Exchange (EMIX) Version 1.0. 11 January 2012.

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

[EnergyInteroperation]
Energy Interoperation Version 1.0, 18 February 2012. http://docs.oasis-open.org/energyinterop/ei/v1.0/energyinterop-v1.0.html

[WS-Calendar]
OASIS WS-Calendar Version 1.0, 30 July 2011. OASIS Committee Specification. http://docs.oasis-open.org/ws-calendar/ws-calendar-spec/v1.0/cs01/ws-calendar-spec-v1.0-cs01.pdf

1.1.2 Other References

[SEP2]
Smart Energy Profile 2.0 Public Application Protocol Specification, Version 2.0 Draft 0.7 Third Release, July 2011. ZigBee Alliance et al. http://zigbee.org/Standards/ZigBeeSmartEnergy/Version20Documents.aspx

2 Block & Tier Prices

In this section we describe California-style Block & Tier tariff information, and the price inflection points that you need to know to determine prices. We describe Block & Tier price inflection points and explore a specific example including how the example Block & Tier information is expressed in EMIX [EMIX] and in SEP 2.0 [SEP2]. We use terminology for Intervals and Gluons from [WS-Calendar].

We conclude by showing how any application environment that can express Block & Tier price information can construct that information from an EMIX information exchange.

2.1 Description of the Problem

There are two or more Consumption Tiers, determined as a percentage of a baseline number, which in turn is determined by the climate zone of the premises, hence is known for each premises.

For concreteness in our example we assume that the baseline value is 1000 kWh, and that the percentage amounts separating the tiers are at 100%, 150%, and 200%, defining four Consumption Tiers.

For premises within a given Consumption Tier there is a price that depends on time of day. We assume in our example diagrams that the times are:

Low 9pm to 10am the next day
Shoulder/Mid 10am to 2pm and 6pm to 9pm
High 2pm to 6pm

An application might deliver information for varying time ranges; we analyze the information structure and note that the information content for (say) weekends would be expressed similarly.

2.2 Information Exchange

EMIX is an integration information model, designed with building blocks to express common characteristics of market information including price. One cannot assume that all communicating applications will use precisely the same information models, so one must plan for information mapping or transformation where the information is received. In EMIX, information can be combined for a rich expression of anything from price and product applied to a single interval to complex schedules over extended periods of time, with or without gaps.

A human gathers information from many sources, from newspapers, web pages, radio broadcasts, and mail delivery of letters. Reading about the energy prices tomorrow in any of those takes the information expressed in many different formats and media and is transformed into the information understanding in the human’s central nervous system. No one says, “I’ll only read prices in the newspaper if they’re in precisely the format I like.”

Likewise a facility will receive information on energy prices tomorrow from web pages, radio broadcasts, point-to-point messages, and other means. To act based on the semantic information about price, the application must take information from multiple sources in multiple formats.

One cannot assume that all recipients share precisely the same information modeling approach, or that (even if they do) they change or update their models at exactly the same time. Complex systems that do not take advantage of interchange or integration information can be brittle, and hard to manage and evolve without a high level of care. By limiting the coupling between provider and consumer information models, Service-Oriented Architectures allow for independent evolution behind the information exchanged.

2.3 Scoping of the Problem

To demonstrate mapping to any Premises system that can handle the Blocks & Tiers, it suffices to demonstrate expression of the information model required by those tariffs. We have in effect an array where one dimension is Consumption Tier number and the other is time.

Consumption Tiers are defined by the cut points and identified by numbers 1, 2, 3, and 4 in the following table. Time is defined by intervals. In the illustration the times are described as “Low, Shoulder, and High” in Table 1.

*Max*	100%	150%	200%	over
*min*	0	1000	1500	2000
*max*	1000	1500	2000	999999
*Consumption Tier*	1	2	3	4
*Low*	0.10	0.11	0.12	0.13
*Shoulder*	0.20	0.25	0.27	0.32
*High*	0.30	0.50	0.60	0.65

Table 1 Price in Dollars Per Kilowatt Hour

This defines a two-dimension array; an application would find where it is in the Consumption Tiers, and then read the price for the current or future time of day. So the key information is exactly that, given the time of day and Consumption Tier, one can tell the Block & Tier aspect of the current price^{^[1]}.

This array is expressed in EMIX, leveraging the structures for demand charges (industrial in the US, residential and industrial in much of the rest of the world), as follows:

(1) Each time interval (Low, Shoulder, High) is described as a WS-Calendar Sequence, e.g.

a. Low: midnight to 10am and 9pm to midnight (two intervals)

b. Shoulder: 10am to 2pm and 6pm to 9pm (two intervals)

c. High 2pm to 6pm (two intervals)

(2) In the alternative a sequence of intervals can be defined with the appropriate tier information attached (starting at midnight, durations of 10h, 4h, 4h, 3h, 3h)

(3) Each time interval has a sequence of Consumption Tier cut points, expressed as maximumEnergyLevel of the high point.

(4) Retrieval algorithm: Select the right time interval for time of day; select the correct consumption tier.

Applications may choose to, and likely will, express this information differently. For example, an array of 60-minute intervals could point to the Consumption Tier structure for that interval. Moreover, an EMIX artifact could express the information in other ways, say with Gluons that respectively reference the Low, Shoulder, and High price tiers.

Clearly this applies only to applications that maintain their own model of a Block & Tier tariff. Since such an application has a means of interpreting the information model (cut points and time intervals) that application can then describe the mapping from a received EMIX artifact to its own information model.

More complex Block & Tier structures, e.g. ones with different price levels or consumption levels on weekends or holidays, or seasonal differences can be expressed in a similar manner.

3 Information Structure for Block & Tier

3.1 EMIX Information Structure

The EMIX information structure describes Intervals, each with a list of consumption tiers.

A Gluon references a Sequence [WS-Calendar] and contains inherited information such as currency, units, scale, and what is measured. Thus each time Interval and ConsumptionTier has common information.[2]

EMIX has a rich expression for price and product information. The mechanisms used for Block & Tier are similar those that in EMIX are used to describe so-called ratchet tariffs, where exceeding demand charge thresholds may affect price for months.

Figure 1 EMIX Information Structure for Block & Tier Example

3.2 SEP 2.0 Information Structure

We describe information structures from SEP2.0 Draft 0.7 – Third Release [SEP2], which represents the Consumption Blocks & Tiers with a list of TimeTariffIntervals, each of which has zero or more ConsumptionTariffIntervals. This expresses the information in Table 1 as shown in Figure 2 with time intervals across the top and the tier values in columns below.[3]

Figure 2 SEP2 Information Structure for Block & Tier Example

For clarity Figure 2 omits many details including inherited optional attributes. Consumption tiers are represented by the minimum usage amount, which is apparently represented as startValue. There is also the powerLimit in the RateComponent object, which is apparently the maximum power permitted by the tariff.

3.3 Comparison of EMIX and SEP 2.0 Information Structures

The SEP2 information structure is very similar to the EMIX information structure. As we see the graphical representation is essentially the same except for attribute names.

The EMIX tiers are identified using the maximum, rather than the minimum levels, so the series in our example would be {1000, 1500, 2000, maximum allowable power which we abbreviate maxPower}. In contrast, SEP2 tiers have additional information, determined by the Block & Tier inflection point structure, apparently intended for application use, e.g. numPriceLevels that is defined by the price inflection points.

There are other differences. For example, the following information items are represented in the EMIX interchange information in the Gluon, and in the SEP2 application environment are in an instance of the ReadingType class:

Currency
Energy as used in the definitions
Multiplier or scale factor

4 Summary and Conclusions

We have shown how both EMIX and SEP2 can express the information model of a Block & Tier tariff. Any application that supports such tariffs can take and place the information on price inflection points from an EMIX expression in its own data structures.

A concrete mapping can be made directly for any application environment that describes its mapping of the Block & Tier tariffs. We have described in detail EMIX and SEP2 express Block & Tier information. More generally, we have demonstrated that such a mapping exists from EMIX to any application that supports Block & Tier tariffs—the same information mapping that the application uses to express Block & Tier information is used to place the necessary price inflection points in that application’s internal data structures.

This is the essence of constructing applications using Service Oriented Architectures and integration approaches—the information gets through; how it’s maintained internally is the business of the receiving application..

The process demonstrated, of understanding the application model and then mapping the required information in to it, is also replicable for any target data structure that models Block & Tier prices.

Appendix A. Acknowledgments

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

Participants:

Bruce Bartell, Southern California Edison

Edward Cazalet, Individual

Toby Considine, University of North Carolina

William Cox, Individual

David Holmberg, National Institute of Standards and Technology

Some contributions and techniques in this note were used, along with additional examples related to SEP2 and demand response signals, as

William Cox, David Holmberg, and Don Sturek, OASIS Collaborative Energy Standards, Facilities, and ZigBee Smart Energy, Grid-Interop 2011, Phoenix AZ, December 2011.

Appendix B. Revision History

Revision	Date	Editor	Changes Made
01	27 September 2011	Toby Considine	Template with notes
02	08 October 2011	William Cox	Rewrite from previously contributed Block & Tier Information note.
03	13 October 2011	David Holmberg, William Cox	Minor editorial corrections. Updated footer numbers and WD numbers in preparation for Public Review
04	11 April 2012	William Cox	Corrected diagrams. Referenced Grid-Interop paper.
05	12 June 2012	William Cox	Updated all references, and applied minor editorial corrections

[1] Other charges may be in a bill, e.g., usage based or customer based; we are expressing the more complex model for Block & Tier price only.

[2] Unless a specific cell needs different information. For example, if many of the prices are 0.30, then that value could be carried in the Gluon and inherited rather than expressed directly. The information model is identical, but the expression may be compressed in this manner for communication.

[3] In this and other examples, optimization may be possible depending on how the application software traverses the structure. Such optimizations do not affect our discussion.