Pricing Concepts for Discussion

[ed@cazalet.com]

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