57A0FF3672494567B7B792E2F056B136@us.schneiderelectric.com"
type="cite">
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 | *: phil.davis@us.schneider-electric.com | : Website: http://www.schneider-electric.com
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
bob.old@siemens.com
www.siemens.com
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
bob.old@siemens.com
www.siemens.com
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
________________________________________________________________________
This email has been scanned for SPAM content and Viruses by the MessageL
abs Email Security System.
________________________________________________________________________