OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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: Toby.Considine@gmail.com
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] | [List Home]