[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [energyinterop] Conformance and Market Contexts and Program descriptions
If I am not mistaken, OpenADR 1.0 included Maximum Notification (prior to event) as well. The list in EMIX came for the existing generation response markets, as listed in the CIM, and had a few added from OpenADR. I somewhat arbitrarily divided them into economic and process (requirements and constraints). I would further divide the Process-based into schedule and non -schedule. We also generalized them, so if something was “MaximumConsecutiveDays” (do not request DR more than 3 days in a row) to “MaximumConsecutiveDurations” (supports “do not request more than three hours in a row” or “do not request three weeks in a row”) The full list, as of now, is: minimumResponseDuration The shortest Duration for which the resource will accept a request to maintain a response before returning to pre-request levels. 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 Schedule Constraints (all drawn from OpenADR 1.0) availabilitySchedule A schedule of times for 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 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. Economic Requirements (Drawn from today’s Generation markets) 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 "He who fights with monsters should look to it that he himself does not become a monster, and if you stare long into an abyss, the abyss also stares into you." - Fredrich Nietzche
From: Girish Ghatikar [mailto:gghatikar@lbl.gov] Hi Toby, I look a this differently and much simpler requirement. The constraints we want to add are purely based on the need of the markets (and defined by them). Of course, there will be many more that the future markets will determine and that is part of every standardization process and most of the requirements included in EI -- things evolve as we move on. Here, wer're defining the requirements for both current and future market needs. The real question is what are the minimum set of requirements that a market needs right now? From the ones you've suggested, I would say (plus more) the following as it relates to a specific program (or universal) per resource (not sure if it has to go all the way to the asset): - Availability Schedule (includes both date/time such as black-out dates/times) - Minimum Notification Time (prior to the event) - Maximum Run Time (duration/window during the event) - Maximum participation days for consecutive event days There might be others that the TC may determine are necessary. Thanks, -Rish On Mon, Apr 25, 2011 at 7:42 AM, Toby Considine <Toby.Considine@gmail.com> wrote: Some off-list comments have led me to think about the number of possible constraints, wand whether every system needs to understand all of them. This concern is closely allied with the related issue that Constraints are extensible, so a given market could create their own. In some domains, people use “must understand” flags on some semantic elements, suggesting that “If you do not understand this, you must refuse to accept request”. WS-RM carefully distinguishes between “I received the message intact” and “I received the message and understood it”. Question: If there are forty kinds of constraints, and a given market context (with its specific market rules) decides that *it* wants to use only 3 of them, say (arbitrarily): Availability Schedule Minimum Notification Time Maximum Run Time Is there a way to express in the market rules that only those three are accepted? Is there a way for an VEN to communicate that it does not understand some constraints? Is this in our out of scope? 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]