[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [energyinterop] Price is an instrument.....
Ed, I totally agree with you! RTP has become the hammer for all
energy nails. We need to make sure everyone understands and is clear on the
distinction between market-driven/based interactions vs. explicit dispatch.
Horst – Although I may not agree with all the column values – I think
you have the best table I’ve seen thus far. I think it should be used as the baseline
for further conversations.
With kind regards,
My comments inserted into your text below noted by my initials in
brackets: [GRH: ]
I had some research into some related concepts a while back that I
thought I could offer. I think what the chart below (source contained in
the attached spreadsheet) uses the term “Message type / Tool” in the left
column header to indicate what Ed refers to as the “set of instruments”.
Ed let us know if this a correct analysis?
In this sheet I had lined up the “instruments” on the left as the
tools that could be called upon to support the programs represented across the
top. One could probably argue that the list on the left could be reduced
some and perhaps more programs listed at the top. But I guess the point
is that the “Programs” are basically unlimited and will be added every time new
need or tariff is introduced. Yet a good (hopefully small) set of
instruments/tools should meet the needs of any program, current or future and
could be designed into any product (current or future).
I believe Maryann had some similar work, or was it OpenADR
mentioning fast response SR and other similar messaging?
In reading Ed’s note, it reminded me of the concept in the attached
sheet. So I offer it for “what it’s worth”. If you open the
attached sheet in Excel, when you hover your mouse over the list at the top or
left, a brief description should pop up. The selections (Y/N/Maybe) in
the matrix are up for discussion.
Gale R. Horst
Electric Power Research
From: Edward Koch [mailto:firstname.lastname@example.org]
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.
[GRH: I think this is a good point and makes sense to clarify
that PRICE is not the answer to both market-based and explicit-dispatch.]
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.
[GRH: I think this would get cumbersome to have to know their
thresholds where they will respond to price. This supports the Ed’s early
paragraph regarding separating price and explicit. ]
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.
[GRH: Makes sense to me]
the end this distinction may be somewhat minor.
[GRH: From the residential and appliance perspective, I think
this is a significant distinction that we may need to retian.]
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
[GRH: I obviously like the concept. The messages are simple
and few in number. But they rely on a good understanding by the technical
implementers of how they are expected to respond. I believe it was Bill
that mentioned something on the call today about enabling a healthy competition
among the device manufacturers regarding how well they respond, and how they
inform the consumer, and how will the consumer response options are implemented.
I think this is supported by the concept Ed is describing. ]
The set of instruments is rich enough
to allow Utilities to develop a wide range of different types of DR programs or
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
The semantics and syntax of the
instrument is rich enough to be properly interpreted by the end devices and
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.
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
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.