emix — archive
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]
Normalizinh Price and Load Resources
The [uncompleted draft] work in the CIM has some inconsistencies in how it signs up loads. During the initial resource definitions, I pared those extensively, removing, for example, nameplate data, control system information, and other facts beyond those necessary to make economic decisions. There were also inconsistencies between the definitions for Load and for Power resources. I summarize the CSD01 interfaces below (and in the attached documenta, for those who have plain-text mail…
RegisteredGenerationType
OfferLoadReductionType
OfferPowerType
ResourceLoad
Generic
(Registered Generator from CIM)
(LoadBid in CIM)
raiseRampRate
dropRampRate
raiseRampRate
dropRampRate
stagingRamp
maximumOperatingPower
minLoad
maximumPower
minimumLoad
maximumResponse
minimumOperatingPower
minLoadReduction
minimumPower
minimumResponse
dropRampRate
pickupRate
dropRampRate
raiseRampRate
recoveryRamp
spinReserveRamp
minLoadReductionInterval
minimumResponseInterval
minTimeBetLoadRed
minimumTimeBetweenCalls
shutdownCost
startupCost
invocationPrice
LoadReductionPriceCurve
offerSegment
priceRamp
minLoadReductionCost
minimumResourceCost
minimumResponseCost
Some notes )and thanks to Bruce for his work highlighting these issues:
1)
We have a very similar starting ramps[s], min response, max response, finishing ramp[s]
2)
We have a response time.
Ramps. The CIM takes a Ramp (begin value, end value) and has a directionality attribute. We take a ramp, assign directionality (ramp up, ramp down), and then the begin and end values. There are a couple ways we could do this, but these are essentially identical constructs.
Integral response: Each ramp could perhaps have some sort to integrity flag, i.e., all or nothing. Sit or Stand, but requesting crouching is illegal. This is particularly useful for DR (Turn off Chiller or turn off Chiller and Lights) but could be useful for Power as well—particularly for renewables which may not have control.
Price requirements. Some of the CIM objects had price curves. Some did not. The last megawatt may be more expensive to buy than the first. Alternately, now that I have already sent everyone home, it may not cost much more to turn off all the lights. Price curves look like ramps in structure. Not all markets accept curves. Today’s market rules award different prices than those offered. (Often it is sum up all offers until you get enough, then award all that clearing price). I think we need a price curve, which is only incompletely described.
Constraints. I mentioned them earlier today.
I think I see a new top-level EMIX object, EmixOffers, which consists of Terms, Constraints, and a Price Ramp. The price curve would also include the requirements such as invocationPrice and minimumResponsePrice.
This would reduce the four above to Power and Load. Power Ramps UP during Start and Ramps Down afterwards. Load Ramps Down during Start, and Ramps Up afterwards.
Discussion?
tc
“It is difficult to get a man to understand something, when his salary depends upon his not understanding it”
--
Upton Sinclair.
Toby Considine TC9, Inc
OASIS Technical Advisory Board TC Chair: oBIX & WS-Calendar
TC Editor: EMIX, EnergyInterop
U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee
Email:
[email protected]
Phone: (919)619-2104
http://www.tcnine.com/ blog: www.NewDaedalus.com
Power and Load Resources.xlsx
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]