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: RE: [energyinterop] Price is an instrument.....



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]
Sent: Wednesday, September 09, 2009 2:28 PM
To: Edward Koch; energyinterop@lists.oasis-open.org
Subject: RE: [energyinterop] Price is an instrument.....




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 Institute (EPRI)
Office: 865-218-8078

From: Edward Koch [mailto:ed@akuacom.com]



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]