[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [energyinterop] Price is an instrument.....
Ed; 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. Enjoy, Gale
Gale R.
Horst Electric
Power Research Institute (EPRI) From: Edward Koch
[mailto:ed@akuacom.com] 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. [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.] 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. [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. ] 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. [GRH: Makes sense to me] In 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.] 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: [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. ] 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 |
Demand Response Activation Matrix.xls
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]