RE: [energyinterop] Pricing Concepts for Discussion

["Ed Cazalet" <ed@cazalet.com>]

All

Relevant to this pricing discussion is the "Report to NIST on the Smart Grid Interoperability Standards". The report states the following:

6.1.1 Common Pricing Model Standard
The need for a common pricing model crosses all domains that use price. Price is more than a simple number; it carries market context, and information such as quantity, units, time for use, and characteristics including source type and potentially carbon characteristics. A common and interoperable pricing model is a key to Demand-Response systems, Dynamic Pricing in all its forms, and energy markets and trading including forward markets.
The complexity of tariff structures and content means that to fully understand a price one needs to fully understand thousands of pages of tariffs for each jurisdiction. Driving toward simplified tariffs or (at minimum) machine-readable descriptions of tariffs would lead to more efficient markets. For example, the machine-readable tags for end user license agreements have simplified licensing decisions; a similar markup language for tariffs would allow better decisions in markets without implicit knowledge beyond price.
Key Actions:
(1) Develop and standardize a pricing model – NIST should work with IEEE, IEC, OASIS, ASHRAE, NAESB and other relevant SDOs to develop an approach for developing a common pricing model to traverse the entire value chain. The model must include price, currency, delivery time, and product definition.


Also, in this document are many use cases and references to pricing we can utilize.

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: Edward Koch [mailto:ed@akuacom.com] 
Sent: Saturday, July 25, 2009 5:59 PM
To: Ed Cazalet
Cc: michel@universal-devices.com; energyinterop@lists.oasis-open.org
Subject: Re: [energyinterop] Pricing Concepts for Discussion

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
>
>