[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [energyinterop] Price is an instrument.....
Gale, I think your table is an excellent
analysis and is valuable input to deriving the type of instruments I was
referring to. For each row we could drill down and ask the question as to
what type of information (i.e. instrument in my previous email) would be sent
in a DR signal to perform that function. I hope you don’t mind if I
steal some of this (with proper attribution of course) and use it for some of
the PAP 09 use case work we are doing. -ed koch From: Horst, Gale
[mailto:ghorst@epri.com] 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: 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]