Re: [energyinterop] Pricing Concepts for Discussion

[Edward Koch <ed@akuacom.com>]

Ed C,

I was thinking of the potential for more sophisticated hedging
mechanisms involving third parties providing a hedge on prices to
consumers in exchange for control of some of their load.  Of course
that requires more than just dynamic prices, but also a change in how
markets are currently regulated.

-ed koch


On Jul 25, 2009, at 4:09 PM, "Ed Cazalet" <ed@cazalet.com> wrote:

> Ed Koch
>
> I also hope and believe we can come up with a set of signals that
> will deal
> with dynamic pricing and at least some of the DR signals. Since
> dynamic
> pricing is in an early stage of development and is key to the
> success of the
> Smart Grid, I suggest we concentrate separately on dynamic pricing
> and DR
> and then bring them together as we can.
>
> I am interested in your comment that third parties might manipulate
> the
> consumption side in a dynamic pricing implementation.  I assume this
> would
> involve assumption of market power or collusion in the real-time
> market, but
> I am not sure this is what you have in mind.  Would you explain
> further?
>
>
> Separately I would also like to directly address Toby's requests in
> the
> Energy Interoperation Version 0.1 Draft.  In section 4 on Energy
> Markets he
> suggests I comment on the following markets:
>
> Day Ahead Pricing
> Hours Ahead Pricing
> Five minute pricing
>
> Generally Day-head, Hours-Ahead and Five Minute Pricing are concepts
> in US
> ISO and RTO markets and in some cases markets in other countries.  Our
> standard must provide interfaces to such existing markets but should
> allow
> for other markets in operation elsewhere or other market types as
> may be
> developed in the future.
>
> The US ISO and RTO markets are auction markets where generators submit
> orders (bids) to the market operator in day-ahead, hour-ahead. and
> five
> minute markets.  The market operators clear such orders and inform the
> participants of transactions in the market and their net positions
> (schedules) . Market participants are bound to these positions.  Day-
> ahead
> positions can be changed by transactions in subsequent hour-ahead and
> real-time markets.  Differences between final positions (schedules)
> and
> actual metered deliveries are typically settled at the 5-min real-time
> prices.
>
> For loads to participate in the ISO and RTO markets requires orders
> (bids)
> to be submitted. This can be burdensome for small loads.
> Intermediaries may
> offer prices (orders) to load customers to make this easier so loads
> can
> automatically respond to such prices.
>
> Other markets may evolve that post and clear dynamic forward prices
> (orders)
> that change with wind forecasts and other variables, for example.
>
> Hence we need to define orders/transactions/positions to cover all
> likely
> market styles including those in place today.  I believe the
> framework I
> suggested below is a first step towards that objective.
>
> Ed Cazalet
>
>
>
> 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: Edward Koch [mailto:ed@akuacom.com]
> Sent: Saturday, July 25, 2009 9:37 AM
> To: Ed Cazalet; michel@universal-devices.com;
> energyinterop@lists.oasis-open.org
> 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
> ---------------------------------------------------------------------
> 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
>
>