[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [energyinterop] Thinking about Constraints and Market Context
I feel there is still a lot of confusion to work out and discuss at our call today. A Resource (DR, DER, Generation) is an emix thing. A commodity ( electricity, gas, etc. is another emix thing. A Resource is a capability to produce a product. It is not a product. We can call a resource a different kind of product if we want to but when we use the same name, product. for both it leads to confusion. PRODUCT A Product is a commodity transacted at a location, for an interval of time or a set of intervals, at a rate of delivery or total delivery over each interval and at a price for the set or sequence of intervals.
A Tender for a Product is a Buy Tender or a Sell Tender. A Tender is good until withdrawn or it expires. Some argue that is would be useful to apply further constraints as to when the tender can be accepted by the counter party and constraints on what time of day acceptance can happen. Constraints should not be used to describe the sequence of intervals in a tender as that is already provided by the product definition applied to the WS-Calendar intervals and gluons. An option on a Product is either a call or put option or perhaps a combination of the two. An option is a standing tender that the option holder pays the option maker to make available. There may be time windows and exercise lead times for that specified when the option can be exercised and turned into a Transaction. RESOURCE A Resource is a capability to produce products. When control (dispatch rights) are sold from one party to another it is the capability that is exchanges and not the products. When the resource is dispatched products are produced and consumed. Typically Resource Capability descriptions are more complex than product descriptions because the capabilities of the machines or the load curtailment process) that produce the product must also be described. In the case of generation resource there are often economic requirements such as startup costs, minimum load costs in addition to the price of any products produced. PROPOSAL Don’t try to mix tenders and transactions and options for Products with Interactions for Resources. Edward G. Cazalet, Ph.D. 101 First Street, Suite 552 Los Altos, CA 94022 650-949-5274 cell: 408-621-2772 From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine Sent to EMIX as well. I think that I created considerable confusion by falling into a specification honeypot, seizing on semantics from EI, applying them to EMIX, and causing confusion to both groups. Thanks to Rish and Ed C, who spent considerable time straightening me out yesterday. What follows is a narrative of my confusion. If you want to cut to the chase, skip down to the heading “PROPOSAL:” At the beginning of the year, we had twice as many schemas in EMIX as now, and the relationships between them were muddy, or “not properly normalized”. In particular, the information types in power and resource were repetitive, overly particular, and not evolvable. I returned to the CIM market interfaces, and reviewed carefully the non-control and non-technology market characteristics of bids offered into the generation market. I used the generation market because it included the most expansive elaborations in the CIM. These information elements had some common issues that varied from market to market. Notification time is the poster child for this. Every market has some sort of required time which the seller requires after notification to be able to deliver, and every market as some sort of required time within which the seller must deliver to be acceptable. In January, Anne Hendry pointed me to the NIEM guidelines for extensibility and evolvability, and I began rather mechanically sub-typing across all the schemas. One schema led to another, and then the next and soon I was wondering what to call those market requirements or market characteristics or performance expectations. At the end of January, we were running through service definitions at a high level in Energy Interoperation, relying primarily, IIRC, OpenADR 1.0 and the IRC contributions. A critical term appearing in those schema-fee services was the word constraints. This was when I drove into the ditch. In a somewhat schizophrenic manner, I called everything in the emix-requirements.xsd “constraints”. This has caused trouble ever since. Let’s call them kumquats for now instead. These things are properly part of product definition. 4 second responsive power gets sold at considerably higher prices than does 20 minute responsive power. Some power can be sold for long times, and other products must stop and recharge after only brief use. These are characteristics of the product, or of the service offered. They are identical for generation or DR resources. Most of them are the same for power products as they are for natural gas, high pressure steam, low pressure steam, chilled water, or … Here I point out that the EMIX TC has created 3 schemas. EMIX describes the basic market information needed to describe any product in which there is a tight link between production and delivery, and between value and time of delivery. This characterizes many energy markets, not just the electrical power market. This purpose is explicitly called out in the TC charter. Kumquats properly belong in EMIX not in POWER. The Charter also calls out the explicit needs of the Electrical Power Market. The Power Schema extends base types defined in the EMIX schema and adds information specific to Power. For the first time Real Power and Real Energy are introduced to the semantic model. If a product is tendered with a maximum duration of 10 minutes, that kumquat is defined in the emix-requirements portion of the emix-schema. If the same produce has a maximum real-power, that cannot be described within EMIX without creating a loop referring up to POWER for the definition. Instead, power-specific kumquats are defined inside the power resources schema as an extension of the base kumquat class. This dual location is appropriate if we mean to keep the severability of schemas, necessary for evolution and re-use, but has confused a few. At the same time, my appropriation of the word constraints for the kumquats left out a critical elements of the OpenADR constraints. In OpenADR 1.0, no constraint is complete until the Constraint Behavior is defined. The meant that I was presenting again and again something called constraints that did not meet the larger requirements of Constraints as defined in OpenADR. PROPOSAL For EMIX The base-type formerly-known-as-baseConstraint (the kumquat) should be renamed marketRequirement or marketExpectation or something similar. The names of each instance of a [kumquat] should be reviewed to remove confining references to particular markets, i.e., maximumResponseDuration, that create false dichotomies between DR, Generation, and DER. For EI YAC’s (yet another citrus) are published describing how to apply a [kumquat] within a market context. Maybe the YAC is still a constraint, maybe it’s a marketRule. When the smart toaster gets brought home from the store, it queries the VEN to find a Market Context and gets the YACs. Once it knows the YACs, the Toaster can determine whether to offer its capabilities into the market, and how to configure its user interface. That decision, and that interface, are, of course, left to the markets to determine. A YAC consists of: · A kumquat · A Constraint Behavior · A kumquat processing rule. This is cruder than the ConstraintBehaviors. It includes such directives a as “MustUnderstand”, “MustIgnore” YACs describe the expectations for both sides. OpenADR, then defines a very specific set of kumquats that it respects. TEMIX limits itself to a very small set of kumquats (MinimumNotificationDuration?) that it respects. The Toaster can plug in, query the market context, and adjust its communication style to OpenADR 2.0, TEMIX, or other markets not yet named. A future market could create a new market [kumquat] within EI or even in a private schema, and publish a YAC “mustUnderstand”, and be ready to go. One aspect that got brought into all Tenders in EMIX was a side, “BUY” or “SELL”. These become critical to understanding YACs and kumquats. When a SELL publishes a MinimumNotificationDuration of 5 minutes, it means “5 minutes or greater”. When a BUY publishes a MinimumNotificationDuration of 5 minutes, it means “5 minutes or less”. I think YACs are always published from the perspective of the “BUY”, but that could be an interesting set of discussions. tc “The single biggest problem in communication is the illusion that it has taken place.”
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]