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
