[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [energyinterop] Thinking about Constraints and Market Context
Thanks The Market Requirements (constraints) defined in PR02 emix-requirements.xsd are: minimumResponseDuration The shortest Duration for which the resource will accept a request to maintain a response before returning to pre-maximumResponseDuration The longest Duration for which the resource will accept a request. minimumRecoveryDuration The minimum Duration that the Resource requires after the end of a response the resource has is ready to respond to a new request. minimumDurationBetweenInvocations The minimum Duration that the Resource requires after receiving a request before the resource has is ready to respond to a new request. minimumNotificationDuration The minimum Duration that the Resource requires for Notification before initiating a response to a request. maximumNotificationDuration The maximum Duration in advance of a requested response that the resource is willing to accept a request. responseTime Duration required from receipt of a request to initiation of a response by the resource maximumInvocationsPerDuration Maximum number of invocations of service during a given duration maximumConsecutiveDurations Maximim consecutive durations in which service can be invoked, e.g., it will not accept requests on more than 3 consecutive days. minimumStartsPerDuration The fewest Requests that the resource will accept during any duration. This constraint is typically used in market rather than in resource descriptions. maximumRunDuration The Maximum duration for which a resource will accept a request minimumRunDuration The Minimum duration for which a resource will accept a request availabilitySchedule A schedule of times for which which a resource will accept requests. The schedule may include multiple availability windows. The scheduled duration must be entirely within an availability window. notificationSchedule A schedule of time during which a resource will accept requests. The schedule may include multiple availability windows. The notification must occur within an availability window. unavailabilitySchedule A schedule of times for which which a resource will not accept requests. The schedule may include multiple unavailability windows. The scheduled duration must not occur within or overlap an unavailability window. minimumEconomicRequirement Minimum net remuneration this resource requires from a total response requiredStartupCost Minimum remunuration required from start-up of this service. minimumResourceCost Resource requires this amount per period, i.e., a minimum requirement for $100 / hour at whatever rate tc "It is the theory that decides what can be observed." - Albert Einstein
From: Edward Koch [mailto:ed@akuacom.com] Someone told me that this email did not go through to the list so I’m sending it again. From: Koch, Edward All, I won’t be able to attend the conference call on the constraints issue today, but that is probably OK from my perspective. I actually don’t feel a burning desire to get into the details. Since I spoke up on this topic in the EI meeting yesterday let me just take a few moments to state my personal position on this topic. From a technical/structural point of view I really don’t care if the schemas for constraints are defined in EMIX or EI, BUT that being said from a process and procedural point of view I “might”. We in EI have requirements for constraints. The folks in EMIX have told us they will define constraints in their schemas that we can use. I’m not involved in EMIX, nor do I want to be, so to that I reply fine - here’s what we need in EI and let me see what you produce and hopefully we can use it. Where I start to object is whenever the topic of constraints comes up in EI there is a knee jerk reaction that whatever we are going to do with constraints in EI somehow MUST come from EMIX and if what we need in EI is not covered then we MUST go over to EMIX and fix their spec. It’s hard for me not to question that position when I start hearing dissention among the EMIX people on the topic of constraints within their spec. It naturally raises the questions of whether EI should be relying on EMIX to define constraints. My recommendation is simple. The EMIX folks should get their act together on this topic so the EI folks can review what they produce and judge its usefulness. Furthermore if their specs are lacking in some respect the EI folks should be free to derive extensions to them to suit their needs without having to wade into EMIX and insist they change their spec accordingly. Thanks, -ed Koch 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]