Re: [energyinterop] Algorithmic price signals

[Girish Ghatikar <GGhatikar@lbl.gov>]

Ed,

All the current implementations of Critical Peak Pricing within 
California IOU's use PRICE_MULTIPLE for transmitting CPP DR event 
information. It's required because, that's how the utility DR programs 
and CPP tariffs are designed. Please see the application manual for CPP 
and DBP programs that describes details on these functionalities and how 
it ties to control strategies within facilities: 
http://drrc.lbl.gov/pubs/PGE-AppManual_CLIR-SW_2-R3.pdf.

For PRICE_RELATIVE, there is no current example of commercial 
implementation. Although, when the Peak Day Pricing (PDP) program within 
Pacific Gas and Electric rolls out, it will likely use PRICE_RELATIVE as 
the program design is a price "adder" (e.g., $1.20/ kHh) and the 
requires OpenADR to send relative prices.

Other than supporting utility/ISO program unpredictable design and 
tariffs, there are other wider benefits of these type IDs that will 
allow OpenADR to support dynamic pricing programs and not just RTP. We 
need to understand that RTP is a form of dynamic pricing and other 
dynamic pricing programs may evolve. The Participating Load Pilot with 
PG&E/CAISO also included the customers participating in the CPP programs 
to use the same control strategies to participate in ancillary services 
market. We need to acknowledge the requirements of demand-side as well. 
With some of TC members coming from the IT world knows well that 
backward compatibility is critical and implications can be negative if 
not considered.

The similar rationale also applies to other reliability-based types 
LOAD_AMOUNT, LOAD_PERCENTAGE, LOAD_LEVEL, etc. They all have different 
meanings and also tie to control strategies for demand-side.

Ed may have more examples.

With all that said, I think we should also have a strong rationale on 
what's wrong in inclusion of other types of prices when a data model 
structure can easily support without any additional complications?

Thanks,
Rish

Edward G. Cazalet wrote:
> 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].