OASIS Energy Interoperation TC

  • 1.  Conformance and Market Contexts and Program descriptions

    Posted 04-25-2011 14:43
    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.” – George Bernard Shaw. Toby Considine TC9, Inc 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    


  • 2.  Re: [energyinterop] Conformance and Market Contexts and Program descriptions

    Posted 04-25-2011 16:52
    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.? ? George Bernard Shaw. Toby Considine TC9, Inc 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     -- Rish Ghatikar Lawrence Berkeley National Laboratory 1 Cyclotron Road, MS: 90-3111, Berkeley, CA 94720 GGhatikar@lbl.gov +1 510.486.6768 +1 510.486.4089 [fax] This email is intended for the addressee only and may contain confidential information and should not be copied without permission. If you are not the intended recipient, please contact the sender as soon as possible and delete the email from computer[s].


  • 3.  RE: [energyinterop] Conformance and Market Contexts and Program descriptions

    Posted 04-25-2011 19:22
    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 Toby Considine TC9, Inc 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     From: Girish Ghatikar [mailto:gghatikar@lbl.gov] Sent: Monday, April 25, 2011 12:52 PM To: Toby.Considine@gmail.com Cc: energyinterop@lists.oasis-open.org Subject: Re: [energyinterop] Conformance and Market Contexts and Program descriptions   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.” – George Bernard Shaw. Toby Considine TC9, Inc 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     -- Rish Ghatikar Lawrence Berkeley National Laboratory 1 Cyclotron Road, MS: 90-3111, Berkeley, CA 94720 GGhatikar@lbl.gov +1 510.486.6768 +1 510.486.4089 [fax] This email is intended for the addressee only and may contain confidential information and should not be copied without permission. If you are not the intended recipient, please contact the sender as soon as possible and delete the email from computer[s].