[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Thinking about Constraints and Market Context
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]