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