Drat!
Of all the sessions to miss, this topic (M&V) is where I have spent years of
"quality" time. Darn those pesky customers, anyway. A few key point
in the field application of DR:
1. The ISO's have market rules that can result in calls for
increased loads (regulation support) under certain circumstances, so the result
of DR (response, not reduction) can be +/-. The + is rare but growing, and
promises to be the crux of DR 3.0.
2. In traditional DR programs, there are three constructs, and
not all have baselines. Most commonly, baselines are calculated
from the the past N days' demand excluding certain types of days, but
regardless, that formula is decreed by market rule. When an event is
called, current status is not terribly relevant as the goal is to perform in
relationship to the established baseline. In some cases, the customer may
already be there due to circumstance, or it may be impossible to get there,
again due to circumstance. Macht nichts as far as the ISO is
concerned.
An
outgrowth of that conundrum is that some market rules call for a reduction
against that baseline, some call for a reduction to a specific level (no
baseline), and others call for a reduction by a specific amount from current
state ("instant" baseline). There is a variant that involves guarantee not
to exceed a certain value, but to me, this is the obverse of dropping to a
specific level.
3. Verification does involve the revenue meter but in today's
world, this is not a direct link. While there may be leads attached to
revenue meters, most often, the demand data submitted for
settlement comes from submeters, CT's, or control system consoles.
Over time (and it can be a long time), this settlement data is validated against
the utility meter and payment is made if the two agree within a preset tolerance
level. There is never an exact match since DR events and utility read
intervals almost never sync.
There
are countless variations. On site generation can use name plate data
rather then metered data, for example, and I've even seen settlements based on
the amount of diesel consumed during events. Never underestimate an
engineer's ability to introduce complexity.
As my
kids would say TL;DR (google it, old folks).
At
your service.
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 |
*: | : Website: http://www.schneider-electric.com
From: Old, Bob [mailto:]
Sent: Thursday, March 11, 2010 12:15 PM
To: Energy Interop;
Subject: FW: [emix] Not To
Exceed
Sorry Toby, I forgot to click
reply-all.
Robert Old
Siemens Industry,
Inc.
Building
Technologies
1000 Deerfield
Pkwy.
Buffalo Grove, IL
60089-4513
Tel.: +1 (847)
941-5623
Skype:
bobold2
www.siemens.com
From: Old, Bob
Sent: Thursday, March 11, 2010 11:13 AM
To:
''
Subject: RE: [emix] Not To
Exceed
My expectation for verification
is that the utility meter information is required. I’ve also heard that in
a curtailment scenario, just promising to reduce load by a certain amount around
uncertain beginning and end points is a non-starter.
The programs I’ve heard of give
you a baseline for the next day, below which you have to reduce by some
program-determined amount and for which you get a program-determined level of
compensation. Sometimes the program specifies that the baseline will be
calculated on something like “the highest/lowest usage over 5 of the last 6 day
which don’t include weekends/holidays/days with an event called.” But
sometimes they just give you the number and you do your own modeling.
We’re talking money here.
It needs a revenue grade meter.
Best,
B.O. March 11,
2010
Robert Old
Siemens Industry,
Inc.
Building
Technologies
1000 Deerfield
Pkwy.
Buffalo Grove, IL
60089-4513
Tel.: +1 (847)
941-5623
Skype:
bobold2
www.siemens.com
From: Toby Considine
[mailto:] On Behalf Of Toby
Considine
Sent: Thursday, March 11, 2010 10:43 AM
To:
;
Subject:
[emix] Not To Exceed
DR – and Verification, and
Verification is the conundrum. Verification is the problem because DR are is a
promise to reduce load by a certain amount from an uncertain beginning end point
to an unknown end point.
What about an agreement that “I
will use no more than xxx” as a DR offering. It becomes entirely results
oriented (good for a service). It would be more valuable if it warranted “no
spikes” rather than merely total use for a [15 minute] period. It certainly
would be callable.
Do we adopt this? If so,
does it look like
[emix – this is for max
use]
Or does it look
like
[Eitc: I will commit not to
exceed
[emix]
]
In other words, is max an EITC or
EMIX thing…
tc
"Energy and
persistence conquer all things." -- Benjamin Franklin
Toby Considine
TC9, Inc
OASIS Technical Advisory Board
TC Chair: oBIX &
WS-Calendar
TC Editor: EMIX,
EnergyInterop
Email:
Phone: (919)619-2104
http://www.tcnine.com/
blog: www.NewDaedalus.com
________________________________________________________________________
This
email has been scanned for SPAM content and Viruses by the MessageL
abs Email
Security
System.
________________________________________________________________________
