[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [energyinterop] RE: Algorithmic price signals
|
David, As I remember, a bar-chart of pricing on the PG&E website
for the PDP program called it an Adder, not a multiplier. I don’t understand why the Load Serving Entity can’t
just give me a price. They know me individually, don’t they?
They know I’m an authorized program participant. They probably want
to know whether I’m opting out of a specific event. Many times they’re
giving me my individual curtailment baseline. Best, B.O. April 21, 2010 Robert Old Siemens Industry, Inc. Building Technologies 1000 Deerfield Pkwy. Buffalo Grove, IL 60089-4513 Tel.: +1 (847) 941-5623 Skype: bobold2 bob.old@siemens.com www.siemens.com From: Holmberg, David
[mailto:david.holmberg@nist.gov] 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:ed@akuacom.com] 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]