[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]