[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emix] Definition of a "Price Interval"
Rish, Phil, Based on your comments, here are my thoughts. ·
Some DR or price programs have "scheduled
events" versus "unscheduled events". By that I mean, I can know
that every day at 4pm I will get the next 48 hours of estimated hourly prices,
and that every hour I will get an update on the next 12 hours with the next two
hours fixed. So, if those are events, then they are scheduled events like
getting the mail delivery. Even DR programs may have fixed time intervals (or
patterns) when called. And DR programs are scheduled (called) maybe day ahead.
So, we have the case of everything fixed and known ahead, as for RTP, and
alternatively, unknown time intervals (varying lengths) scheduled ahead of time
by some notice (could be very short notice). Does that leave out any DR program
or RTP program? ·
Seems for DR events, we need a flexible time
interval with contained event parameters (per Rish's original email). But
do we need this structure if we know the time intervals ahead of time? Do we
always need end time? We should have a format that allows reduction to only
giving start time, no end, and only giving the start time of the first
interval, and not of subsequent (maybe giving the constant time interval
length). But maybe the only advantage is conserving bits (and this is not worth
much)? ·
There should be a program identifier at the
start of a message so I can choose to pay attention or not. Or I guess you get
the message (pull/push) only if in that program. ·
Then a message type, since a program might have
different basic messages, i.e., the notice of event vs. the actual data, or the
48 hour price data vs. the 12 hour data. Sorry if these are things discussed before...
-----Original Message----- Phil, I agree that this would be a good way of moving forward
(so are thoughts from Ed Cazalet). On your question of sending a constant stream data for
all events. I am not fully certain how the RTP programs will be structured
within the service providers. WIthin CAISO there are many RTM
prices. Hence, I think we should be independent of how the programs gets
structured in future and the data models be flexible enough to allow
that. I agree with your other part of the question that the receiving
systems (e.g., clients within facilities) should be able to select
relevant information. I'd be glad to have a separate discussion on current use
of OpenADR within California and its potential within other areas
you've discussed. In summary, we've initiated discussion within some of
these areas and looking at that opportunity. The PLP was funded by
PG&E and generally, our resources/funds are mostly for California programs.
I'd be very interested to get other agencies engaged for wider
applications. Thanks, Rish Phil Davis wrote: > Girish, > > I believe we are in violent agreement, but I was
being unintentionally > obtuse. When I read your example code, my
initial impression was that > the price was unique to that DR product and to the
time in which it > was called. Based on your subsequent
explanation, I believe we are in > agreement that the relevant interval here is
time. There are separate > streams of data, "event type" and
"price", that are coincident with > the time interval but are not a specific function of
it; i.e., all are > independent variables. > > This implies that a control authority could send a
constant stream of > data covering all events and times, and that the
receiving system > could be configured to select only that data
relevant to the local > facility. True? > > Your references to CAISO do inspire another
question. OpenADR > together with the studies cited are only California
oriented. Our > OASIS members in France (Laurent Guise and
Francois Jammes) have > asked if the work being done has any non US centric
input. Are you > aware of any international applications? Also,
has there been any > affirmative activity to see if OpenADR specs would
function within the > market rules of the other US ISO's? ERCOT
LaaR, PJM Regulation and > ISO-NE FCM all require automated response and either
are in the field > or are close to implementation. It will be
difficult to promote > OpenADR as a national standard if it does not
encompass the parameters > of these programs. It probably does, but it's
politically important > to be able to refer to specific studies. > > Thanks! > > Phil > >
------------------------------------------------------------------------ > *From:* Girish Ghatikar [mailto:GGhatikar@lbl.gov] > *Sent:* Saturday, April 03, 2010 8:29 PM > *To:* emix@lists.oasis-open.org > *Subject:* Re: [emix] Definition of a "Price
Interval" > > Phil, > > Thanks for bringing this up and I think this is the
*issue with > terminologies and NOT the concept of use of time for
intervals*. > > Based on my interactions during technology
integration of CAISO > real-time market (RTM) with OpenADR, we have seen
that intervals could > be used in different contexts. What you have is a
definition of "price > intervals" is one element. For example, for
CAISO, under "prices" on > -- http://oasis.caiso.com/mrtu-oasis/ -- the
intervals are used for > time, price, etc. as seen below by definitions. > > *"Interval Locational Marginal Prices*:
Five-minute Locational > Marginal Prices for all PNodes and all APNodes in
$/MWh, for each > *five-minute interval RTM*. Posts the LMP, plus the
Congestion, Loss > and Energy Components that makes up the LMP." > *"Interval AS Clearing Prices*: Ancillary
Services Regional Shadow > Price for all Ancillary Service types for all
binding AS Regions and > Sub-Regional Partitions. Posts 15-Minute price
relevant to the next 15 > minute *binding interval for RTM* on a fifteen
minute basis." > > *While I think the "monetary interval" you
have is one important > element for DR*, other element is also the
"time interval." For > example, the time interval will determine the
end-uses that could be > part of DR strategies and for what duration (or
not). The length > (time) and the breadth (kW) are equally important.
The price will > determine their willingness to participate and time
will determine if > they can and by how much. This was also one of the
thing we looked at > the recently concluded participating load pilot
(PLP) that we > conducted with CAISO (see below). > > *Open Automated Demand Response Communications in
Demand Response for > Wholesale Ancillary Services* > Kiliccote S., M.A. Piette, G. Ghatikar, Lawrence
Berkeley National > Laboratory; E. Koch, D. Hennage, Akuacom; J.
Hernandez, A. Chiu, O. > Sezgen, Pacific Gas and Electric Company; and J.
Goodin, California > Independent Systems Operator. In the Proceedings of
the Grid-Interop > Forum 2009, Denver, CO, November 17-19, 2009.
LBNL-2945E. November 2009 > http://drrc.lbl.gov/drrc-pubs-auto-dr.html > > Moving forward, I think we should acknowledge this
and be clear of > terminologies that are in use and have a certain
meaning -- they > should retain their meaning as much as possible. > > Thank you, > Rish > > > > > > Phil Davis wrote: >> Keep in mind that when the ISO's refer to price
interval in their >> reports and analysis documents, they are
referring to a monetary >> interval rather than a time based
interval. In other words, there is >> a $15 price interval between an LMP of $45/mwh and
$60/mwh. Most >> usage in analysis is asks questions like
"at what price interval do >> large facilities respond to DR
signals". These kinds of studies >> influence incentives and subsidies, and may
inform rate making in >> regulated constructs. However, in the
markets, the actual prices >> themselves are known well in advance of Dr
events since they are set >> at auctions. >> >> When modeling/forecasting for grid operations,
the ISO's will use >> this research to determine the likelihood of
calling an event and the >> cost of that event, given weather predictions at
various degrees of >> confidence (of the weather). Because of
the usage, I would reverse >> the wording somewhat; i.e., that for a given
time interval, there >> should be a price associated with it.
Recipients would use this >> data, especially in automated systems either to
auto respond or to >> signal managers if prices exceeded a pre-set
level. >> >> This happens to be a period of rapid rules
change following a >> relative period of stability. Predictions
are troublesome at best, >> but there seems to be a national trend toward
eliminating specific >> pricing for DR, and paying all parties the
generation equivalent of >> the energy product produced. this is not
without controversy, so our >> wisest course might be to allow for showing
prices for DR and for the >> underlying energy. This would support a
value calculation that >> encompasses both the overt value of DR plus the
value of the avoided >> purchase of energy for the same time interval. >> >> Phil Davis >> >>
________________________________________________________________________________________________ >> *Phil Davis** | Senior Manager *| Schneider Electric
Demand Response >> Resource Center | 3103 Medlock Bridge Road, Ste
100 | Norcross, GA >> 30071 | (: 404.567.6090 | 7: 678.672.2433 |
Skype: pddcoo >> *: phil.davis@us.schneider-electric.com >>
<mailto:phil.davis@us.schneider-electric.com> | : Website: >> _http://www.schneider-electric.com_ >> >> >> >> >> >> >>
------------------------------------------------------------------------ >> *From:* Girish Ghatikar
[mailto:GGhatikar@lbl.gov] >> *Sent:* Friday, April 02, 2010 8:06 PM >> *To:* emix@lists.oasis-open.org >> *Subject:* [emix] Definition of a "Price
Interval" >> >> This came up during last week's eMIX TC meeting
-- *What is the >> definition of price interval? What
elements/attributes are comprised >> in it?* >> >> For any price, there should be a standard
"Time" factor associated >> with it (unless the exception is there is
"one" price for all periods). >> >> >> I think we should make a key distinction of
price schedule versus the >> interval (if we ever can) and how the generic
price intervals are >> different from their definition in DR signals
(the notion of DR events). >> >> Let's say for example, a price-responsive DR
event in OpenADR may >> look something like this (I am not saying this
is how eMIX should >> address it as the goal of sending the
information and subsequent >> response may differ) -- >> >>
<p:drEventData> >>
>>
<p:notificationTime>2010-02-08T15:17:21.000-08:00</p:notificationTime> >>
<p:startTime>2010-02-09T00:00:00.000-08:00</p:startTime> >>
<p:endTime>2010-02-09T23:59:59.000-08:00</p:endTime> >>
<p:eventInfoInstances> >>
<p:eventInfoTypeID>PRICE_ABSOLUTE</p:eventInfoTypeID> >> <p:eventInfoName>price</p:eventInfoName> >>
<p:eventInfoValues> >>
<p:value>0.03638841</p:value> >>
<p:timeOffset>0</p:timeOffset> >>
</p:eventInfoValues> >>
</p:eventInfoInstances> >>
</p:drEventData> >> >> What you see above is a definition of time slot
(start and end time) >> that has various attributes associated with it.
Other attributes >> could be for example, load shed, % shed, etc.
However, all of these >> attributes are associated with one time-slot
notion, which is defined >> by the period of DR event. >> >> Thank you, >> RIsh >> >> -- >> Rish Ghatikar >> Lawrence Berkeley National Laboratory >> 1 Cyclotron Road, MS: 90-3111, Berkeley, CA 94720 >> GGhatikar@lbl.gov | +1 510.486.6768 | +1
510.486.4089 [fax] >> >> This email is intended for the addressee only
and may contain >> confidential information and should not be
copied without permission. >> If you are not the intended recipient, please
contact the sender as >> soon as possible and delete the email from
computer[s]. >> >> >>
________________________________________________________________________ >> This email has been scanned for SPAM content and
Viruses by the MessageL >> abs Email Security System. >>
________________________________________________________________________ >>
--------------------------------------------------------------------- >> 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 > > -- > Rish Ghatikar > Lawrence Berkeley National Laboratory > 1 Cyclotron Road, MS: 90-3111, Berkeley, CA 94720 > GGhatikar@lbl.gov | +1 510.486.6768 | +1
510.486.4089 [fax] > > This email is intended for the addressee only and
may contain > confidential information and should not be copied
without permission. > If you are not the intended recipient, please
contact the sender as > soon as possible and delete the email from
computer[s]. > > >
________________________________________________________________________ > This email has been scanned for SPAM content and
Viruses by the MessageL > abs Email Security System. >
________________________________________________________________________ >
--------------------------------------------------------------------- > 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 -- Rish Ghatikar Lawrence Berkeley National Laboratory 1 Cyclotron Road, MS: 90-3111, Berkeley, CA 94720 GGhatikar@lbl.gov | +1 510.486.6768 | +1 510.486.4089
[fax] This email is intended for the addressee only and may
contain confidential information and should not be copied without
permission. If you are not the intended recipient, please contact the
sender as soon as possible and delete the email from computer[s]. --------------------------------------------------------------------- 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]