I have felt a growing recognition that the California-centric aspects of OpenADR have been a significant barrier not only to the specification’s adoption, but to participation in this TC. We must be careful to restrain the impulse to support everything ever done anywhere.
Many tariffs are crude shims built around not having real time usage, not having real-time communications, and not having agreed upon descriptions of the performance required—so they focus on process rather than service. Step functions, and any rachets other than peak demand are examples of this. Multipliers and adders may be a separate case, and that case may be more defensible, but I am not convinced yet.
Phil’s detailed perspective below explores these notions.
tc
"If flies are allowed to vote, how meaningful would a poll on what to have for dinner be, and what would be on the menu?" - Unknown
Toby Considine Chair, OASIS oBIX Technical Committee
Co-Chair, OASIS Technical Advisory Board
Facilities Technology Office
University of North Carolina
Chapel Hill, NC | | Email: Toby.Considine@ unc.edu
Phone: (919)962-9073 http://www.oasis-open.org blog: www.NewDaedalus.com |
This is one of those occasions where I wish I could be in two places at one time. Anyway, based on reading the email exchanges, and fully aware that we're talking about possibilities here, there may be a few practical issues to bear in mind.
California is the only market where the utilities run the DR programs. Elsewhere, these prices are set at auctions, as you know, and the trend (or reality in several programs now) is for DR resources to react automagically when the price feed reaches the commitment value, or that in reliability settings everyone gets the price set by the highest accepted bid. This is true even where the utility acts as the CSP. There are bilateral programs in non market areas, but I'm not sure there is much of a return on trying to encompass the variations in all those.
Keeping up with tariff structures will drive us crazy. We have folks that do this for a living, and I cannot tell you how often we, the utility, and the customer cannot manually calculate an invoice and reach the same result. As you know, commercial invoices often are done in Excel because no one can agree on what to tell the programmers to structure in billing systems. I am aware of one IBM plant that has its electric bill based on the water consumption of the chillers. Given that audits typically show a percent of commercial utility bills are inaccurate (this listserv doesn't go to any utilities right?), this is far from an exact process.
DR response tends to come from a different mix of local assets than those involved in consumption. It is likely that a tariff constructed around the latter would be misleading in calculating the former. Since outside California, the prices are set in the wholesale market, the majority of those interested (and who are not yet aware of OpenADR) would have no need for a derivative capability.
Overall, the longer it takes to establish a national OpenADR standard, the more likely markets outside California will be to have moved beyond the point of economically justifying adoption. My recommendation would be that we give priority to a "good enough" standard to get established, then revisit this topic.
Phil
________________________________________________________________________________________________
Phil Davis | Senior Manager | Schneider Electric Demand Response Resource Center | 3103 Medlock Bridge Road, Ste 100 | Norcross, GA 30071 | (: 404.567.6090 | 7: 678.672.2433 | Skype: pddcoo *: phil.davis@us.schneider-electric.com | : Website: http://www.schneider-electric.com
From: William Cox [mailto:wtcox@CoxSoftwareArchitects.com]
Sent: Wednesday, April 21, 2010 10:00 AM
To: Holmberg, David
Cc: Edward Koch; energyinterop@lists.oasis-open.org
Subject: Re: [energyinterop] RE: Algorithmic price signals
Isn't that more of an offset? For example, some DR projects use 5/15 minute wholesale prices with a consistent addition or multiplication? I'm not sure that the price "signal" should have a computational element in it, however.
Thanks!
bill
--
On 4/21/2010 9:33 AM, Holmberg, David wrote:
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
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
________________________________________________________________________
This email has been scanned for SPAM content and Viruses by the MessageLabs Email Security System.
________________________________________________________________________