This
is one of those occasions where I wish I could be in two places at one
time. Anyway, based on reading the email exchanges, and fully aware that
we're talking about possibilities here, there may be a few practical issues to
bear in mind.
California is the only market where the utilities run the DR
programs. Elsewhere, these prices are set at auctions, as you know, and
the trend (or reality in several programs now) is for DR resources to react
automagically when the price feed reaches the commitment value, or that in
reliability settings everyone gets the price set by the highest accepted
bid. This is true even where the utility acts as the CSP. There are
bilateral programs in non market areas, but I'm not sure there is much of a
return on trying to encompass the variations in all those.
Keeping up with tariff structures will drive us crazy. We have
folks that do this for a living, and I cannot tell you how often we, the
utility, and the customer cannot manually calculate an invoice and reach the
same result. As you know, commercial invoices often are done in Excel
because no one can agree on what to tell the programmers to structure in billing
systems. I am aware of one IBM plant that has its electric bill based on
the water consumption of the chillers. Given that audits typically show a
percent of commercial utility bills are inaccurate (this listserv doesn't go to
any utilities right?), this is far from an exact process.
DR
response tends to come from a different mix of local assets than those involved
in consumption. It is likely that a tariff constructed around the latter
would be misleading in calculating the former. Since outside California, the
prices are set in the wholesale market, the majority of those interested (and
who are not yet aware of OpenADR) would have no need for a derivative
capability.
Overall, the longer it takes to establish a national OpenADR
standard, the more likely markets outside California will be to have moved
beyond the point of economically justifying adoption. My
recommendation would be that we give priority to a "good enough" standard to get
established, then revisit this topic.
Phil
________________________________________________________________________________________________
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 *: | : Website: http://www.schneider-electric.com
From: William Cox
[mailto:]
Sent: Wednesday, April 21,
2010 10:00 AM
To: Holmberg, David
Cc: Edward Koch;
Subject: Re: [energyinterop] RE:
Algorithmic price signals
Isn't that more of an offset? For example, some DR projects use 5/15
minute wholesale prices with a consistent addition or multiplication? I'm not
sure that the price "signal" should have a computational element in it,
however.
Thanks!
bill
--
William Cox
Email:
Web: http://www.CoxSoftwareArchitects.com
+1 862 485 3696 mobile
+1 908 277 3460 fax
On 4/21/2010 9:33
AM, Holmberg, David wrote:
Ed,
I
agree that we should support common DR programs. If we really don’t like
something for whatever reason, we can indicate that said function is NOT
preferred and why and encourage future programs to use the recommended path.
But, didn’t we also discuss the concept of an “adder”, that is, an amount that
the price is increasing that is broadcast? Are there existing programs for
that?
Thanks,
David
From: Edward Koch [mailto:]
Sent:
Tuesday, April 13, 2010 8:03 PM
To:
Subject:
[energyinterop] Algorithmic price signals
All,
This email is in
response to an action item from the last EI meeting for me to provide
justification for so called “algorithmic” price signals. Algorithmic
refers to communicating information on how to calculate the price as
opposed to the actual prices itself. Examples include price multiples
and relative price offsets. Let me preface my discussion by saying that all
the consideration I am giving below are in relation to EI and DR signals as
opposed to the considerations within EMIX. If EMIX decides that they
will not support algorithmic price representations then that does not
automatically imply that EI does not either. It simply means that if EI
wants to support algorithmic price signals then they will be done in a manner
not specified by EMIX. This would not be the end of the world since EMIX
does not specify other type of signals that may be used in EI such as
dispatches and shed levels, etc.
The first issue is
that of policy. A committee for developing standards for how to exchange
information related to tariffs should not be in the business of designing
those tariffs. We need to understand the full range of tariffs so that
as many different tariffs as possible can be supported. We need to give
the people that actually do design tariffs as much flexibility as possible and
not constrain their options unless there are good engineering principles as to
why that should be so. Given that in fact there already exist so called
algorithmic tariffs (CPP, PDP, etc.) and their number is growing not
shrinking, the first reality is that we will need to support them. I’m
going to assume therefore for the sake of discussion that whatever we do we
will support tariffs like CPP (i.e. price multiple). The question then
becomes how do we support a price multiple tariff like
CPP.
The easiest answer
to that is to simply send the price multiple with the signal and this is in
fact what is done today with OpenADR. The benefits of doing this are that the
information in the signal closely reflects the nature of the tariff. The
alternative is for the Utility to calculate what the actual price is for EACH
customer before sending it and then just send the actual price. From a purely
engineering perspective there are a couple of reasons why that might not be a
good idea. The first is that doing this implies that EVERY price
communication is potentially different for each customer because their base
rates are different. Not only does this potentially add an unnecessary
burden on the entity sending the signals to calculate and send a special
signal for each recipient, but it also means that the new prices can not be
broadcast out, they must be communicated in a point to point fashion. That
adds a processing burden on the head end AND a network capacity burden to
accommodate all the different signals to individual customers. Of course
that level of processing and networking capacity may need to exist for other
reasons, but I’m not a fan of designing systems that require increased
capacities if they are not required, especially for something that seem so
trivial as a price multiple. It reduces your options when it comes time
to optimize and scale things later on.
Some people may
argue that algorithmic prices are bad because it requires the receiver of the
price multiple to know precisely what their base rates are in order to know
what the true price is. That may be true IF they need to know what their
true price is, but consider the opposite side of the coin which is what if
they did not know their own base rate and they were just sent an actual price
instead. In that scenario they would not know where in the price
multiple tariff they were operating unless of course they know what their base
rate is. They’ll either have to know what it is by default or they are going
to have to remember what their previous rates were and try to notice when they
go up by some multiple. In either case they are working off some notion of
their base rate and you haven’t eliminated the need for them to know it.
One could argue
that knowing the dynamics of prices is more important than knowing the actual
price and to some people knowing that their rates just doubled is more
important than knowing the actual price and in that scenario they don’t need
to know their base rate.
I think there are
good reasons to give price multiples, but I will also concede that there may
be good reasons to send actual prices, even for DR programs like CPP that
truly are algorithmic tariffs. The solution is to support both in the
standard and let the people who design the signals and systems that support
the algorithmic tariffs decide. If there is a compelling enough reason,
a signal for a specific program could be designed that actually sends BOTH a
price multiple AND an actual price level as part of the same signal. Or
perhaps let the customer decide which form of the signal they would prefer to
consume by designing a system and set of signals that can support either.
There could be either multiple service endpoints or some form of
parameters that allow the customer to decide what form they would like the
information. I’m not advocating any of these specific solutions, but what I am
advocating is the ability to make these sort of engineering decisions and not
be constrained by the standard in this regard.
I therefore contend
that we should support algorithmic price representations in EI in addition to
actual prices.
-ed
koch
________________________________________________________________________
This
email has been scanned for SPAM content and Viruses by the MessageLabs Email
Security
System.
________________________________________________________________________
