RE: [energyinterop] Algorithmic price signals

["Edward G. Cazalet" <ed@cazalet.com>]

Girish and Ed,

It would be helpful to have some examples of the use of PRICE_MULTIPLE and
PRICE_RELATIVE and especially what Price the multiple or the price adder is
related to.  Also, explaining the advantages of such a price instead of an
absolute price would also be helpful, including describing what situations
it would apply to.

Edward G. Cazalet, Ph.D.
101 First Street, Suite 552
Los Altos, CA 94022
650-949-5274
cell: 408-621-2772
ed@cazalet.com
www.cazalet.com


-----Original Message-----
From: Girish Ghatikar [mailto:GGhatikar@lbl.gov] 
Sent: Tuesday, April 13, 2010 8:26 PM
To: Edward Koch
Cc: energyinterop@lists.oasis-open.org
Subject: Re: [energyinterop] Algorithmic price signals

Ed,

Very good summary! I am fully supportive of using other event info type 
IDs (e.g., PRICE_MULTIPLE, PRICE_RELATIVE, etc.). I would be surprised 
if we eliminated the "flexibility" and "backward compatibility" of the 
current OpenADR model to integrate with commercial DR programs, 
especially the dynamic pricing programs and instead become 
"restrictive." For me, eMIX overlap relates to a "pure RTP" model or 
PRICE_ABSOLUTE event info type ID. As I understand with eMIX (and Ed 
Cazalet), they're currently following the similar concepts for 
representing RTP for DR events.

In summary, I think we should be inclusive of DR programs and NOT 
exclusive. If we exclude support to existing DR programs, we will 
encounter another problem in future of use of OpenADR and that OpenADR 
does NOT support California DR programs.

Thank you,
Rish

Edward Koch wrote:
>
> All,
>
> This email is in response to an action item from the last EI meeting 
> for me to provide justification for so called "algorithmic" price 
> signals. Algorithmic refers to communicating information on how to 
> calculate the price as opposed to the actual prices itself. Examples 
> include price multiples and relative price offsets. Let me preface my 
> discussion by saying that all the consideration I am giving below are 
> in relation to EI and DR signals as opposed to the considerations 
> within EMIX. If EMIX decides that they will not support algorithmic 
> price representations then that does not automatically imply that EI 
> does not either. It simply means that if EI wants to support 
> algorithmic price signals then they will be done in a manner not 
> specified by EMIX. This would not be the end of the world since EMIX 
> does not specify other type of signals that may be used in EI such as 
> dispatches and shed levels, etc.
>
> The first issue is that of policy. A committee for developing 
> standards for how to exchange information related to tariffs should 
> not be in the business of designing those tariffs. We need to 
> understand the full range of tariffs so that as many different tariffs 
> as possible can be supported. We need to give the people that actually 
> do design tariffs as much flexibility as possible and not constrain 
> their options unless there are good engineering principles as to why 
> that should be so. Given that in fact there already exist so called 
> algorithmic tariffs (CPP, PDP, etc.) and their number is growing not 
> shrinking, the first reality is that we will need to support them. I'm 
> going to assume therefore for the sake of discussion that whatever we 
> do we will support tariffs like CPP (i.e. price multiple). The 
> question then becomes how do we support a price multiple tariff like CPP.
>
> The easiest answer to that is to simply send the price multiple with 
> the signal and this is in fact what is done today with OpenADR. The 
> benefits of doing this are that the information in the signal closely 
> reflects the nature of the tariff. The alternative is for the Utility 
> to calculate what the actual price is for EACH customer before sending 
> it and then just send the actual price. From a purely engineering 
> perspective there are a couple of reasons why that might not be a good 
> idea. The first is that doing this implies that EVERY price 
> communication is potentially different for each customer because their 
> base rates are different. Not only does this potentially add an 
> unnecessary burden on the entity sending the signals to calculate and 
> send a special signal for each recipient, but it also means that the 
> new prices can not be broadcast out, they must be communicated in a 
> point to point fashion. That adds a processing burden on the head end 
> AND a network capacity burden to accommodate all the different signals 
> to individual customers. Of course that level of processing and 
> networking capacity may need to exist for other reasons, but I'm not a 
> fan of designing systems that require increased capacities if they are 
> not required, especially for something that seem so trivial as a price 
> multiple. It reduces your options when it comes time to optimize and 
> scale things later on.
>
> Some people may argue that algorithmic prices are bad because it 
> requires the receiver of the price multiple to know precisely what 
> their base rates are in order to know what the true price is. That may 
> be true IF they need to know what their true price is, but consider 
> the opposite side of the coin which is what if they did not know their 
> own base rate and they were just sent an actual price instead. In that 
> scenario they would not know where in the price multiple tariff they 
> were operating unless of course they know what their base rate is. 
> They'll either have to know what it is by default or they are going to 
> have to remember what their previous rates were and try to notice when 
> they go up by some multiple. In either case they are working off some 
> notion of their base rate and you haven't eliminated the need for them 
> to know it.
>
> One could argue that knowing the dynamics of prices is more important 
> than knowing the actual price and to some people knowing that their 
> rates just doubled is more important than knowing the actual price and 
> in that scenario they don't need to know their base rate.
>
> I think there are good reasons to give price multiples, but I will 
> also concede that there may be good reasons to send actual prices, 
> even for DR programs like CPP that truly are algorithmic tariffs. The 
> solution is to support both in the standard and let the people who 
> design the signals and systems that support the algorithmic tariffs 
> decide. If there is a compelling enough reason, a signal for a 
> specific program could be designed that actually sends BOTH a price 
> multiple AND an actual price level as part of the same signal. Or 
> perhaps let the customer decide which form of the signal they would 
> prefer to consume by designing a system and set of signals that can 
> support either. There could be either multiple service endpoints or 
> some form of parameters that allow the customer to decide what form 
> they would like the information. I'm not advocating any of these 
> specific solutions, but what I am advocating is the ability to make 
> these sort of engineering decisions and not be constrained by the 
> standard in this regard.
>
> I therefore contend that we should support algorithmic price 
> representations in EI in addition to actual prices.
>
> -ed koch
>

-- 
Rish Ghatikar
Lawrence Berkeley National Laboratory
1 Cyclotron Road, MS: 90-3111, Berkeley, CA 94720
GGhatikar@lbl.gov | +1 510.486.6768 | +1 510.486.4089 [fax]

This email is intended for the addressee only and may contain 
confidential information and should not be copied without permission. If 
you are not the intended recipient, please contact the sender as soon as 
possible and delete the email from computer[s].


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php