RE: Algorithmic price signals

Ed,

I agree that we should support common DR programs. If we really don’t like something for whatever reason, we can indicate that said function is NOT preferred and why and encourage future programs to use the recommended path. But, didn’t we also discuss the concept of an “adder”, that is, an amount that the price is increasing that is broadcast? Are there existing programs for that?

Thanks,

David

From: Edward Koch [mailto:ed@akuacom.com]
Sent: Tuesday, April 13, 2010 8:03 PM
To: energyinterop@lists.oasis-open.org
Subject: [energyinterop] Algorithmic price signals

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

energyinterop message