OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

energyinterop message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [energyinterop] Pricing Concepts for Discussion


Ed,

Thanks for your input.  It is very insightful. You are right to point out the debatable relationship between dynamic or real-time pricing tariffs and DR.  In my opinion DR implies specific load profile goals that the Utility/ISO is trying to achieve by invoking a so called "DR event".  This is based upon a need, either economic or for reliability, to explicitely influence the load profiles of their customers.  Clearly price could be a mechanism used for that process, but if you accept the above definition of DR then clearly not all real-time pricing tariffs would be considered "DR."  Dynamic prices could be based upon normal market mechanisms in which prices are set by factors that don't include the need to achieve specific load profiles by the customers.  It follows that if the markets are working effectively then in theory they will naturally flatten the aggregate consumption profiles and thus the need to do DR for reliability purposes should be reduced, although it will never go away.  On the other hand some people think that once the market becomes more liquid there could be a greater desire by third parties to manipulate the consumption side of the equation for financial gains and DR interactions may actually increase.

With that said I should point out that the 1.0 version of the OpenADR spec is focused on DR while the TC charter is for "energy interoperation" which may have a scope that is broader than just "traditional" DR.  Thus all your observations are relevant whether it is applicable to DR or not.  Given the fuzzy line between DR and real time pricing tariffs one would hope that we can come up with an set of signals that can deal with both cases, but after further analysis we may find that is not necessarily the case.


-ed koch


________________________________________
From: Ed Cazalet [ed@cazalet.com]
Sent: Saturday, July 25, 2009 10:41 AM
To: michel@universal-devices.com; energyinterop@lists.oasis-open.org
Subject: RE: [energyinterop] Pricing Concepts for Discussion

Michael

Thank you very much for your comments and feedback.

First, with respect to DR, the pricing concepts herein are more associated with better electricity pricing than with DR.  Whether we think of better electricity pricing as an element of DR. or separate concept is a debate not worth our time, in my opinion.

Second, with respect to your question on standardizing the length of the measurement intervals, I believe some standards will need to be developed.  However, at the level of the protocols (if that is the right word) for defining price signals with orders/transactions/positions we can be more general.  The protocol could be used for flat pricing, where the price never changes.  In this case, monthly intervals and measurement are all that are needed for billing.  It could be used for seasonal pricing or on-peak/off peak pricing.  However, the idea is that the industry will evolve over time, as needed, to more refined measurements and pricing.  The evolution will be not just for managing peak loads but for efficiently balancing the grid on an hourly, 5 min, or perhaps 4 second basis.  The protocol I outlined should handle all such cases.

All consumers and generators on the same grid need not carry out transactions on the same time intervals. For example, some consumers can operate based on hourly time intervals where the hourly price is the average of 12 5-min price.  At the same time large consumers and large generators can operate on a 5 min interval, for  example.  It would be very helpful if all time intervals are synchronized and sub intervals are all contained within a longer interval and do not cross the boundaries of the longer intervals.

Third, you have commented on the importance of price in DR scenarios.  Clearly one's response to price is subjective.  There are also a fairness and economic issues regarding pricing that are presently outside the scope of this discussion.  Directives to cut demand in emergencies may continue to be effective and deployed.
24/7 automated electricity load management to stabilize the grid more efficiently than ramping fossil generation cannot be done with such directives.  With 33% intermittent renewables by 2020 in California and similar requirements in other US states and countries, at some time in the future, we will need to use prices to manage both load and distributed and central generation on the grid, I believe.  Distributed intelligent devices such as your company provides are ideal for responding to dynamically changing prices on more refined intervals'  The response will be automatic and may consider the subjective preferences of each customer and emergency directives.

Best regards, Ed

Edward G. Cazalet, Ph.D.
101 First Street, Suite 552
Los Altos, CA 94022
650-949-5274
cell: 408-621-2772
ed@cazalet.com
www.cazalet.com


-----Original Message-----
From: Michel Kohanim [mailto:michel@universal-devices.com]
Sent: Friday, July 24, 2009 6:36 PM
To: energyinterop@lists.oasis-open.org
Subject: RE: [energyinterop] Pricing Concepts for Discussion

Hello Ed,

I do very much agree with all your points. Some quick questions vis-à-vis DR:

With respect to "Location a meter or set of meters where deliveries can be measured" - and in your view - is there a minimum/maximum interval during which each meter has to be measured? i.e if meters are measured every 2 hours, how does that impact the price/order/transactions? If the impact is substantial, then Should this standard also come up with "measurement interval optimization algorithms" ?

Also, I've been pondering the importance of price in DR scenarios. Although very important, I think from a customer point of view, price and its relevance to ones energy consumption is quite subjective. For instance, during super bowl, price might not even be a factor for those who watch it on their TVs. Whereas something like: "cut your demand by x, y, z factors or you will have no power in w minutes" is much more meaningful.

I'd appreciate your thoughts.

With kind regards,

********************************
Michel Kohanim, C.E.O
Universal Devices, Inc.

(p) 818.631.0333
(f) 818.708.0755
http://www.universal-devices.com
********************************


-----Original Message-----
From: ed@cazalet.com [mailto:ed@cazalet.com]
Sent: Friday, July 24, 2009 12:21 PM
To: energyinterop@lists.oasis-open.org
Subject: [energyinterop] Pricing Concepts for Discussion

All,

Toby suggested I put forth a few paragraphs related to pricing of electricity.

I  am keenly aware of the need for simplicity, clarity etc. in supporting electricity transactions for the smart grid.

I have had the experience of building and operating online electricity exchanges  (Automated Power Exchange - APX ) in many US and foreign markets and overseeing the markets of the California ISO as Board member.

I believe careful definition of  price and transactions is essential and that we might as well use approaches already defined for electricity and other commerce.

Price has little usefulness for transactions unless the amount, location quantity, etc. are also specified.
A price signal is not a well defined term: it could simply be a forecast of a price to be charged for an undefined quantity, an ex-post price to be charged for actual consumption, or a firm offer that is binding on acceptance.

The first challenge is the terminology for a price.

Wholesale electricity markets such as RTOs and ISOs  often define bids ( price and quantity) to buy and sell.  Another term used is offer. Offers can also be a buy or a sell offer.  In other markets a bid specifies a buy price and an offer a sell price.  It is confusing but we get by.

The equivalent term for a stock exchange  bid or offer is an order.  An Order specifies price, amount and more.  An order when matched with another order results in a transaction or contracts.  A series of transactions by a party for a commodity or stock is a position.  I am open to other names for the same concepts.

For now I will used the order, transaction and position terminology from the stock market.  I wont attempt a formal definition in  XML,  or to define use cases  leaving that to the experts.  Note that an end user, a generator, an intermediary, could be generating or receiving orders or doing both.  I am not attempting to limit us to any market design or clearing system.  For example, day-head, hour-ahead and real-time markets could all use the structure below.  For feedback and settlement we also need to define any transactions and how these transactions add up to positions.

Order

To define an order it must specify at least:

Location  a meter or set of meters where deliveries can be measured
Commodity  an electric product such as energy ( could be green energy, wind energy, etc.)
Delivery Interval  an interval defined by a Begin DateTime and End DateTime
Units for power, energy and currency
Price expressed as $/kWh ( for example)
Maximum Amount at the Price above expressed either as energy ( kWh over the Delivery Interval) or average power ( kW over the Delivery Interval)
Buy/Sell  indicate whether the Amount above is for a purchase or Sale
Party  Party initiating the order  could  be an individual, company, ISO or exchange.
Counterparty
Open Date Time  when the price and amount are available ( such as 1 hour before Begin DateTime)
Expiration DateTime - when the price and amount are expires ( such as 5 minutes before Begin DateTime)

Transaction

( similar structure to the Order)

Location  a meter or set of meters where deliveries can be measured
Commodity  an electric product such as energy
Delivery Interval  an interval defined by a Begin DateTime and End DateTime
Units for power, energy and currency
Price expressed as $/kWh ( for example)
Amount expressed either as energy ( kWh over the Delivery Interval) or average power ( kW over the Delivery Interval)
Extended Price  ( Price * Energy)   or (Price * Average Power * Delivery Interval Length)
Buy/Sell  indicate whether the Amount above is for a Purchase or Sale
Party  Party initiating the order  could  be an individual or company or an ISO or exchange.
Counterparty
Transaction DateTime  when the transaction was contracted.

Position
( similar structure to the Transaction)

Location  a meter or set of meters where deliveries can be measured
Commodity  an electric product such as energy
Delivery Interval  an interval defined by a Begin DateTime and End DateTime
Units for power, energy and currency
Total Net Amount of transactions expressed either as energy ( kWh over the Delivery Interval) or average power ( kW over the Delivery Interval)
Extended Price  ( Price * Energy)   or (Price * Average Power * Delivery Interval Length)
Buy/Sell  indicate whether the Total Net Amount above is for a Purchase or Sale
Party  Party initiating the order  could  be an individual or company or an ISO or exchange.
Counterparty


Clearly there is a lot of redundancy above, but I think that is an implementation issue.  Position can always be calculated as needed from the transactions and a transaction could link to the order, etc and save information.  Price and Extended Price are redundant information.  Whether the order, transaction and position amount is expressed as energy, average power, both or either is another choice.

I think these definitions cover all the cases from bilateral transactions, to  bid into ISO and exchange markets and rate base pricing using tariffs.  Orders, transactions and positions can be for a wide range of commodities such as energy, capacity, spinning reserves, curtailment, emergency service, etc.

Forward pricing is done by orders and transactions forward of delivery at different times.  Dynamic forward pricing would provide orders made at various times ahead of the delivery interval.   In some cases it would make sense to transmit vectors of orders and transactions for a given party, thus reducing the redundant transmission of information common among orders for a given commodity and location, for example.

Price signals can be interpreted as prices in the context of a buy or sell offer.  Or a price signal could be indicative only, implying no ability to contract at that price.

Comments are welcome.

Ed Cazalet
ed@cazalet.com
650-949-5274



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]