Agree
that we should be generic. The real data of significance is
available rate of charge/discharge. A traditional generator can go
indefinitely, and traditional demand response (kinda sorta) maintains a steady
state for a defined period of time. Depending on type, storage can behave
similarly, one exception being batteries. As batteries charge or
discharge, the rate at which they do so tends to change, as does the max voltage
available. Of course we (and dare I say others) make marvelous devices to
mitigate the impact of this, but the truth is that batteries never deliver rated
capability for the entire span of a charge/discharge cycle.
So the
question is whether this should be part of the communications, or whether the
grid model learns this via statistical inference from meter data over
time. If the latter, then nothing overt is needed in the comm
record. If the former, then I am at the limit of my ability to expound on
this, having attended liberal arts institutions.
Phil
Push?
Will
that work as well as the Push technologies that are perennially the next wave on
the ‘net
The
correct push is appropriate pricing.
The
correct measure of battery efficiency vs afternoon scarcity is
pricing.
tc
"If
something is not worth doing, it`s not worth doing well" - Peter
Drucker
Never
under estimate an engineers ability to add
complexity!
What
is wrong with the simple notion of % full and capacity total in MW and storage
ratio?!?! Completely agnostic to the storage device
characteristics!!!
If I
know the storage is 60% full and has a total capacity of 100 MW - and a default
ratio of power to storage of 4:1 then I know I can push 40 x 4 = 160 MW at the
device to fill it. Plus if device is sending out updating in intervals - I
might send it 100MW - then it says it is 85% full - so I adjust
accordingly.
Once
it is full it sends "Stop!" - simple!
If
you want to get clever on your backend systems - you may track actual storage
ratio achieved compared to default - or the device can adjust that
itself.
--------
Original Message --------
Subject: RE: [emix] Power storage
strategies
From: "Edward Cazalet" <ed@MegaWattSF.com>
Date: Mon, April
26, 2010 12:04 pm
To: "'David RR Webber (XML)'" <david@drrw.info>, "'Phil
Davis'"
<pddcoo@gmail.com>
Cc: <emix@lists.oasis-open.org>, <Toby.Considine@gmail.com>
Yes,
storage can play a big role in providing ancillary services and supporting the
integration of wind and solar. I am a big advocate of distributed
storage in very large amounts (see my attached editorial on the subject which
has led to pending legislation to promote storage in California). Also
see my storage company's website (www.megawattsf.com) below on this
subject.
Both
of you raise the issue of what is behind the meters including storage.
After thinking about this problem for some time, I think it is too difficult
to communicate what is physically behind the meters. We would need to
know the state of charge of storage devices, the charge/discharge
efficiencies and nonlinearities of each type of battery, battery temperature
that can limit use, and the opportunity costs of storage use. In
some case what is behind the meter changes such as when an electric vehicle is
plugged in, a storage battery is added or removed for maintenance and so
on. And sometimes the storage may be ice storage which is useful when
there is an air conditioning load and less useful when there is not air
conditioning load. And as David said, each storage device needs new
XML.
The
other approach is Transactional Energy, wherein the priced offers and
transactions over current and forward intervals using frequent, small
transactions can fully convey all of the necessary transactional information
on what is behind the meter including any storage with no specifics on the
devices or their state and no special XML. And with forward priced
offers that form a forward price curve, automated self-dispatch of
storage is much easier to do.
Vice
President and Co-Founder
MegaWatt
Storage Farms, Inc.
101
First Street, Suite 552
Can
we get one of those 400 people to write some XML for
us?!?!
If
telephone switch industry is a guide here - this means we already have 3 sets
of battery subsystem XML - GE, Hitachi and Samsung - with more to follow.
And of course each new model has new
XML...
--------
Original Message --------
Subject: RE: [emix] Power storage
strategies
From: "Phil Davis" <pddcoo@gmail.com>
Date: Mon,
April 26, 2010 11:26 am
To: "'David RR Webber (XML)'" <david@drrw.info>,
<Toby.Considine@gmail.com>
Cc:
<emix@lists.oasis-open.org>
Actually,
GE announced such a system last week and is hiring 400 people in Atlanta to
staff the new business. It's a substation level product. Also, I have
spoken personally with people at Hitachi and Samsung who are testing a 1 MW
battery. Such a battery from another vendor is in test operation
behind PJM's main offices. So local here takes on a new meaning depending on
whether it is truly behind the customer meter, or behind the distribution
grid meters (substations and the like), or on a transmission system.
Theoretically, batteries of this size could replace generators used for
voltage or frequency support.
From:
David RR Webber (XML) [mailto:david@drrw.info]
Sent:
Monday, April 26, 2010 10:58 AM
To:
Toby.Considine@gmail.com
Cc:
emix@lists.oasis-open.org
Subject: [emix] Power storage
strategies
It
occurs to me that local storage can potentially play a role here - depending
on its efficiency of course. One can anticipate that future technology
will offer higher % there - especially if market forces drive that
equation.
Therefore
- a future system could offset power surges by drawing on locally stored
resources that were captured during off-peak or excess capacity. In
fact such a system may notify suppliers that they can "push" excess power to
local storage at some pre-determined cost point - and of course also need to
indicate that the storage facility is at a certain % level, or if empty -
accept units at a higher cost rate.
________________________________________________________________________
This
email has been scanned for SPAM content and Viruses by the MessageLabs Email
Security
System.
________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php