OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

energyinterop message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Price is an instrument.....



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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]