[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: FW: [emix] Power storage strategies
Thank you for jumping in with more
information and comments. I think we are on the same track for the most
part. But I have a few clarifications / questions if you don’t mind?
Thanks again Gale R.
Horst Electric
Power Research Institute (EPRI) From: Frances
Cleveland [mailto:fcleve@xanthus-consulting.com] Ed and Gale - Gale, From: Ed Cazalet [mailto:ed@cazalet.com] -------- Original Message -------- Subject: RE: FW: [emix] Power storage strategies From: "Ed Cazalet" <ed@cazalet.com> Date: Tue, April 27, 2010 3:25 pm To: "'David RR Webber (XML)'"
<david@drrw.info>, "'Considine,Toby (Campus Services IT)'"
<Toby.Considine@unc.edu> Cc: <fcleve@xanthus-consulting.com>, "'Phil
Davis'" <pddcoo@gmail.com>, < To continue this excellent discussion. First, for the benefit of Francis below is a link to
White Paper on Transactional Energy that, in part, deals with ancillary
services in a way that I think levels the field between generation, storage and
loads as providers of ancillary services. The idea is to facilitate
energy transactions on shorter intervals including 4-second intervals for
frequency regulation. Download Document: With respect to David's quest for simplicity, I think
we are closer than it might seem. David wrote (italics) : So my real time scenario would run something like
this: 1) Power source queries grid for status of existing
available storage devices with surplus capacity 2) From responses and my available power - I commit
with a couple of them to push power to them - to determine this I just need ROM
calculations that tell me they can absorb the power at the rate I'm generating
it. - their availability should be immediate,
or time when to commence charging - indicate status update refresh period
for 20% change in stored power or full - depending on anticipated storage rate
- this you can calculate - either from history of previous service to that
device - or device itself can give you estimate - if you are off by a % it
won't be a big deal. 3) Commence power distribution 4) Receive regular status updates from devices of
their new storage level and remaining capacity. 5) Compute decision - continue power supply or loop
back to 1) 6) If no storage devices available - then scale back
power generation - until receive storage notification from device available. My revision. 1) Power source queries storage providers or
brokers for quotes to store (buy) 25 MW per hour from 2 am to 5 am ( 100 MWh) 2) Generator accepts the best quote of $25 per MWh. 3) Generator requests quote to store another 100 MWh
for the same hours. 4) Storage providers are full and provide no further
quotes. 5) Generator scales back generation to store only 100
MWh. Note your example talked about where the power was
stored and not what the generator got back ( money or energy) and when.
My example assumes the generator gets money for the stored energy. Perhaps a better transaction with storage is as
follows: Generator requests a quote for storing 100 MWh from 2 am to 6 am
and drawing 80 MWh from 2 pm to 6 pm, ( accounting for a rough 80% round trip
storage efficiency). The storage provider might quote $50 per MWh stored
for this service. Ed Edward G. Cazalet, Ph.D. 650-949-5274 cell: 408-621-2772 From: David RR Webber (XML) [mailto:david@drrw.info] Sent: Tuesday, April 27, 2010 8:02 AM To: Considine,Toby (Campus Services IT) Cc: fcleve@xanthus-consulting.com; Phil Davis; Subject: RE: FW: [emix] Power storage strategies All, I'm still urging for keeping this really simple! From the perspective of the supplier for the surplus
power to push to the storage device - how much precision do you really
need!?!? Frankly I really don't need to know much about the device beyond
how much capacity to a ROM (Rough Order of Magnitude). Why over engineer
this - if you can use simple tracking messages to see how you are
progressing? Remember when a 5Mb hard drive was a big deal?! Expect
market to drive demand for low cost buckets of storage in future... So my real time scenario would run something like
this: 1) Power source queries grid for status of existing
available storage devices with surplus capacity 2) From responses and my available power - I commit
with a couple of them to push power to them - to determine this I just need ROM
calculations that tell me they can absorb the power at the rate I'm generating
it. - their availability should be immediate,
or time when to commence charging - indicate status update refresh period
for 20% change in stored power or full - depending on anticipated storage rate
- this you can calculate - either from history of previous service to that
device - or device itself can give you estimate - if you are off by a % it
won't be a big deal. 3) Commence power distribution 4) Receive regular status updates from devices of
their new storage level and remaining capacity. 5) Compute decision - continue power supply or loop
back to 1) 6) If no storage devices available - then scale back
power generation - until receive storage notification from device available. What I would anticipate is that scenario 6) is really
about always having enough storage capacity available to balance demand. From our XML perspective - so long as our simple
message designs contain enough information to drive the decision making - we
don't need more. E.g. we want minimalistic message design. People
will always think of more and more exotic information that can be added - we
want to strongly resist that - and require ONLY the information needed to drive
a working process - nothing more. Remember - the messages do NOT need to
contain information that can be obtained elsewhere. Otherwise you end up
with a standard that is extremely tough to implement - and then even worse to
have consistent interoperability across vendors. Plus break the messaging
down into small discreet purposes. For example - I do NOT need to send
device profile but once - first time device is available. DW Thanks, DW -------- Original Message -------- Subject: RE: FW: [emix] Power storage strategies From: " Date: Tue, April 27, 2010 9:44 am To: Phil Davis <pddcoo@gmail.com>, " < <emix@lists.oasis-open.org> Cc: "fcleve@xanthus-consulting.com"
<fcleve@xanthus-consulting.com> Well, I think you are correct. The discussion of the performance attributes or an
offering that we skated around last month are really about ancillary services…. Time to respond after request? Ramp time after response? Minimum response Maximum response Maximum sustained response (define sustained) Cycle time… These are all aspects of being able to fit DR to
ancillary markets, not just to “traditional” DR. As most of them
are some sort of “meet or exceed” expectations, the same DR could
be offered to different markets. Alternately, the building owner could easily
see how system augmentation to improve a performance metric would allow the
building to play in a more lucrative market… 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 Email: Toby.Considine@
unc.edu Phone: (919)962-9073 blog: www.NewDaedalus.com From: Phil Davis [mailto:pddcoo@gmail.com]
Sent: Monday, April 26, 2010 9:10 PM To: Cc: fcleve@xanthus-consulting.com Subject: RE: FW: [emix] Power storage strategies Thanks! Phil From: Toby Considine [mailto:tobyconsidine@gmail.com] On
Behalf Of Toby Considine Sent: Monday, April 26, 2010 3:35 PM To: emix@lists.oasis-open.org Cc: fcleve@xanthus-consulting.com Subject: FW: FW: [emix] Power storage strategies I forwarded this conversation to Frances Cleveland,
who is working on electrical standards for storage management (the complicated
process we are trying to stay out of). Thee followed back with a an interesting
analogy of the more valuable types of response dictated by ramp time, response
time, et al. tc "If something is not worth doing, it`s not worth
doing well" - Peter Drucker Toby Considine TC9, Inc OASIS Technical Advisory Board TC Chair: oBIX & WS-Calendar TC Editor: EMIX, EnergyInterop Email: Toby.Considine@gmail.com Phone: (919)619-2104 blog: www.NewDaedalus.com From: Frances Cleveland [mailto:fcleve@xanthus-consulting.com]
Sent: Monday, April 26, 2010 3:06 PM To: Cc: emix@lists.oasis-open.org Subject: Re: FW: [emix] Power storage strategies Toby - Just to add to the mix, I did not see "ancillary
services" in this discussion - these are services like var management,
frequency deviation mitigation, load following, etc. These are huge issues for
utilities, and just like derivatives are often more "valuable" than
stocks in the stock market, are often of more value to the utility than just
energy. If I can't send this directly to the emix list, please
forward .....
At 11:52 AM 4/26/2010, Toby Considine wrote: Sharing the conversation that broke out today in
EMIX… "If something is not worth doing, it`s not worth
doing well" - Peter Drucker Toby Considine TC9, Inc OASIS Technical Advisory Board TC Chair: oBIX & WS-Calendar TC Editor: EMIX, EnergyInterop Email: Toby.Considine@gmail.com Phone: (919)619-2104 blog: www.NewDaedalus.com From: Ed Cazalet [mailto:ed@cazalet.com]
Sent: Monday, April 26, 2010 2:50 PM To: 'Phil Davis'; 'David RR Webber (XML)'; Toby.Considine@gmail.com Subject: RE: [emix] Power storage strategies David, Thanks for getting an informative debate going. I assume that you are suggesting that storage can be
generically modeled as a device with a MWH capacity, a power ratio for both
charge and discharge of say 4 MW per MWH (4 to 1 ratio) and a current state of
charge (% of the MWH energy capacity) with some updating of these parameters as
necessary. Further, I assume you are suggesting that this
information be used by other parties ( and possibly the owners ) to
dispatch the storage. However you have not mentioned how third parties
would be charged or contract for the use of the storage. Keeping with your idea to keep the storage model
simple. we would need at least also specify a round trip efficiency of storage
devices since this efficiency ( MWH Out / MWH in) can vary between 50% and over
90% for various storage technologies. Additionally, some compressed air
energy storage devices (CAES) also require natural gas as an input energy
source in addition to electric energy. ( Note: round trip efficiency is also a
function of state of charge and rate of charge and discharge, but let's say we
ignore that for simplicity.) A fixed power ratio is also problematic for many
storage devices. Many batteries have asymmetric charge and discharge
ratios, so that we would need to specify different ratios for charging and
discharging. Additionally, many batteries are able to charge or discharge
at high rates for short time periods or when they are not near full or not near
empty and then at much lower rates on a sustained basis. Another critical parameter is response ramp
rate. Some devices such as batteries and flywheels have an almost instant
response whereas pumped hydro and CAES have a much slower response, limiting
their value for frequency regulation. What information we provide about storage also depends
on what side of the plane of control (energy services interface) we might be
on. On the storage device side of the interface, the physical models that
you suggest may be useful, however the need to over simplify is less. On the inter domain side of the interface
communicating even a simplified storage model to other parties and then
figuring out how to dispatch that storage in coordination with generation and
load is challenging. If avoiding over complication by engineers and
striving for simplicity is a goal, then I recommend the pure simplicity of
Transactional Energy outside of the plane of control of specific devices.
What is done inside the plane of control is another matter, where the specifics
of each device are much easier to accommodate. With Transactional Energy a storage owner can make or
accept an offer to buy MWH at a given rate and at given low price at night or
when the wind is blowing hard. The amount and price will depend on many
factors such those we have discussed above. The storage owner can also
make or accept an offer to sell energy at a higher price in the afternoon or
when the wind is not blowing. A party could perhaps simultaneously enter
into a transaction to sell in the morning and buy in the afternoon from the
storage owner. This is real simplicity and it is the way we buy and sell
almost everything else in our life.. Perhaps as both an economist and an engineer, I
can revise your statement " Never under estimate an engineer's ability to
add complexity! to say, "Never underestimate the ability of an
economist's market to make simple what an engineer can make complex!" Ed Edward G. Cazalet, Ph.D. 650-949-5274 cell: 408-621-2772 From: Phil Davis [mailto:pddcoo@gmail.com]
Sent: Monday, April 26, 2010 8:27 AM To: 'David RR Webber (XML)'; Toby.Considine@gmail.com Subject: RE: [emix] Power storage strategies Actually, GE announced such a system last week and is
hiring 400 people in Phil Davis From: David RR Webber (XML) [mailto:david@drrw.info] Sent: Monday, April 26, 2010 10:58 AM To: Cc: emix@lists.oasis-open.org Subject: [emix] Power storage strategies Toby, 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. DW ________________________________________________________________________ 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
****************************************** * Frances M. Cleveland * * * * Tel: (831) 338-3175 * Cell: (831) 229-1043 * fcleve@xanthus-consulting.com ****************************************** ________________________________________________________________________ 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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]