All,
I just wanted to further clarify the point I was trying to
make in the call today. I don’t think we actually disagree on the
principles, but perhaps on the “semantics” (pun intended) I think
one of the reasons many Utilities want to use dynamic prices is that they believe
that customer’s interactions in a more free or liquid marketplace will
reduce the need to explicitly dispatch resources for the purposes of grid reliability.
Thus the objective is to foster a different type of participation by the
customer in a dynamic marketplace which will in theory effect the
customer’s consumption in a positive manner. Price is the just the
means to achieve that goal and is used to portray market conditions.
Sending prices is not the end goal, but is the means to achieve a different
type of market participation. On the other hand price can also be used
explicitly as a means to dispatch resources at specific times (i.e. grid
reliability events) and at those times the price may not reflect actual market
conditions, but may be explicitly set to achieve a certain reaction from
customers. In this latter case, instruments other than prices may also be
used to dispatch resources. Thus I think that the distinction between the
different types of interactions between the Utility and the Customer should be
between a market based interaction (which will of course use dynamic prices as
the main instrument) or between an explicit resource dispatch (which may or may
not use prices). The only thing I was objecting to was the use of the term
“price” as a means of differentiating between these two types of
interactions. I think the real distinction should be something along the
lines of “market based” versus “explicit
dispatch”. Both may use prices as well as other instruments.
I think the reason this distinction is important is not
because I think that the building’s reaction will be different if it is
receiving a price signal as part of its free market tariff versus its response to
a price signal as part of a DR reliability dispatch. I think that in
principle a facility’s reaction will not be different. What may
potentially be different though are the other interactions that have to take
place between the Utility and the customer. If the Utility is explicitly
doing a dispatch by setting the price to achieve a particular response (e.g. for
reliability) then it may be important to know in advance what the
customer’s reaction will be at a certain price so that it can know what to
set the price to. This may require interactions that are not necessary in
a purely market based interaction that is based on forces such as supply and
demand. Also in the case where there are explicit dispatches of resources
there may be contractual agreements that require a certain level of
acknowledgement and confirmation between the customer and Utility that may not
be required for a purely market based participation.
In the end this distinction may be somewhat minor.
What is more important is that we define a set of instruments (of which price
is just one) that may be used as part of a DR signal that satisfies the following
requirements:
1) The set of
instruments is rich enough to allow Utilities to develop a wide range of
different types of DR programs or tariffs
2) The
semantics and syntax of each instrument is such that it can be used in a
variety of ways depending upon the nature of the DR program
3) The semantics
and syntax of the instrument is rich enough to be properly interpreted by the
end devices and human operators.
4) The semantics
and syntax of each instrument is not too rich in order to facilitate its easy consumption
by the customer’s devices and end nodes. Note that there are a lot of
dimensions to this requirement ranging from simple syntax/parsing to semantic
understanding by both the machines consuming the signal AND the human operators
that must program/specify rules that will translate the semantics of the
instrument into operational levels or states of the end devices.
These requirements are somewhat mutually exclusive and the
trick is to find the right engineering tradeoff between them. We took a
crack at it in the existing OpenADR specification, but I won’t claim that
it is the definitive way to do it.
Note that in the existing OpenADR specification the
instruments I am referring to above are called “EventInfoType” and
part of a Program definition includes what EventInfoTypes are used in that program.
-ed koch