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


With pleasure!

Some of these have already been addressed with comments from various
members. So,  the main limiting factors for me are:
1. Each event should have a unique ID. Modified events in the current
release should become new events and therefore eventModNumber should be a
structure with the eventId of the original event
2. eventInfoTypeName is currently just a name (such as price). I believe the
eventInfoTypeName should be changed to EventType structure with the
definition of all the Metadata associated with it. This helps machine to
machine communications

Example 
Price: EventType
Price.name="price"
Price.type=Float
Price.precision=3
Price.range.min=0
Price.range.max=1000000000000000
---> Price Specific subclass attribute
Price.currency=USD


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: Considine, Toby (Campus Services IT) [mailto:Toby.Considine@unc.edu] 
Sent: Sunday, July 26, 2009 7:55 AM
To: 'energyinterop@lists.oasis-open.org'
Subject: RE: [energyinterop] Pricing Concepts for Discussion

Now *there* is a very interesting throw away...

A delineation of what you as a practitioner find "a little limiting" would
be very interesting to the committee...


Tc

"A man should never be ashamed to own that he has been in the wrong, which
is but saying ... that he is wiser today than yesterday." -- Jonathan Swift

Toby Considine
Chair, OASIS oBIX TC
Facilities Technology Office
University of North Carolina
Chapel Hill, NC

Email: Toby.Considine@ unc.edu
Phone: (919)962-9073
http://www.oasis-open.org
blog: www.NewDaedalus.com



-----Original Message-----
From: Michel Kohanim [mailto:michel@universal-devices.com]
Sent: Sunday, July 26, 2009 2:40 AM
To: energyinterop@lists.oasis-open.org
Subject: RE: [energyinterop] Pricing Concepts for Discussion

Ed K,

I see that I am not the only one who thinks there's a fuzzy line between
Dynamic Pricing and DR. I am afraid that with the broader scope for this
taskforce, we are going to spend more of our time on commerce/market
interactions rather than refining the Open ADR specs which I have found
quite elegant (although a little limiting).

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


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