energyinterop — archive

"Opt Out" (really cancel during an event in progress)

From: William Cox <[email protected]>
To: [email protected]
Date: Mon, 04 Jul 2011 19:50:00 -0000

Ed - As you say, if this is in PR02 there's a lot more discussion required. And no one in the critical path for PR02 has time for that. I would like us to stop the discussion, and join in an affirmative decision that this is NOT in PR02. I've deferred the issue post PR02 - this is a great discussion; let's take it to the list Thursday. I've said that in at least two emails, and all I see as followup is here's how to do it. I know I've done some of that as well, for which I apologize. There is too much to do in the critical path without adding the necessary discussion on this. AND if there might be any changes, re-doing schemas, diagrams, and specification. This has to be a work item post PR02. Thanks! bill -- William Cox Email: [email protected] Web: http://www.CoxSoftwareArchitects.com +1 862 485 3696 mobile +1 908 277 3460 fax On 7/4/11 2:37 PM, Koch, Edward wrote: 4E5F8FDF186E2E42A40243DCF2EA68E7027D25D5@DE08EV1005.global.ds.honeywell.com type= cite > I keep seeing these emails on this topic. Does that mean that a proposed solution for this is going into PR2? If not then I €™ll quit burning cycles on this right now, but if it is going into PR2 then there are heaps more discussion required including the notion that this is €œreally cancel during an event in progress € . If this is not a PR2 item then lets schedule a meeting in the next two weeks to discuss. From: Considine, Toby (Campus Services IT) [ mailto:[email protected] ] Sent: Monday, July 04, 2011 12:11 PM To: Girish Ghatikar Cc: Koch, Edward; William Cox; [email protected] ; Dave Hardin; Bruce Bartell Subject: RE: [energyinterop] Re: Opt Out (really cancel during an event in progress) 5.4 Naming of Services and Operations The naming of services and operations follows a pattern. Services are named starting with the letters Ei . Capitalization follows the Upper Camel Case convention. Operations in each service use one or more of the following patterns. The first listed is a fragment of the name of the initial service operation; the second is a fragment of the name of the response message which acknowledges receipt, describes errors, and may pass information back to the invoker of the first operation. Create €”Created An object is created and sent to the other Party Cancel €”Canceled A previously created request is canceled Request €”Sent A request is made for all objects of the specified type previously created and relevant to this VTN-VEN relationship Distribute An object (such as a price quote, a curtailment or generation request) is created and sent without expectation of response To construct an operation name for the EiEvent service, Ei is concatenated the name fragment (verb) as listed. For example, an operation to cancel an outstanding operation or event is called EiCancelEvent . The pattern of naming is consistent with current work in the IEC Technical Committee 57 groups responsible for the [TC57CIM] . As it is event related, then we have the form Ei___Event Perhaps language tied more closely to non-performance on an option call €¦. (not that I have a good suggestion) Override €“ EiOverrideEvent - EiOverriddenEvent Refuse - - EiRefuseEvent €“ EiRefusedEvent Decline - - EiDeclineEvent €“ EiDeclinedEvent Deny - - EiRefuseEvent €“ EiRefusedEvent Reject - - EiRejectEvent €“ EiRejectedEvent I agree Cancel is out for the reasons Rish named tc It is the theory that decides what can be observed . - Albert Einstein Toby Considine Chair, OASIS oBIX Technical Committee U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee Facilities Technology Office University of North Carolina Chapel Hill, NC Email: Toby.Considine@ unc.edu Phone: (919)962-9073 http://www.oasis-open.org blog: www.NewDaedalus.com From: Girish Ghatikar [ mailto:[email protected] ] Sent: Monday, July 04, 2011 1:45 PM To: Considine, Toby (Campus Services IT) Cc: Koch, Edward; William Cox; [email protected] ; Dave Hardin; Bruce Bartell Subject: Re: [energyinterop] Re: Opt Out (really cancel during an event in progress) Toby, I am open to the name -- say it as EiOverride if you'd like. Note that an event canNOT be cancelled by the VEN -- only VTNs must have that authority! They can only opt-out or override. The resulting penalty is part of M&V and it's outside the scope of EI. Thanks, -Rish On Mon, Jul 4, 2011 at 10:40 AM, Considine, Toby (Campus Services IT) < [email protected] > wrote: There is * NO * question of not including a service to a VEN to say €œno thanks € during the Notification Period. This function, essential in OpenADR will not be abandoned. All the proposals are about what to call it. As the semantics of the services have evolved, there is a Single OPT service, and the payload of an OPT service is vavailability. Opt-In creates additional Availability on top of the general Availability that was previously described by €œConstraints €. Opt-Out instead replaces the existing Availability with a new one for a distinct period. The Opt Service is clear and consistent and simple €“ which suggests they are correct. The discussion here is appears to be €œThe operation of refusing a an Event by the VEN after notification, known as OptOut in OpenADR 1.0, should be called €¦ € I think Bill €™s proposal is that the eiCancelEvent service be used. An event can be cancelled by the VTN or the VEN. The narrative language goes something like €œA VEN can opt out of an even after receiving a notification by invoking the EiCancelEvent service € If we want the service naming for VEN cancelation and VTN Cancellation to be different, PERHAPS it should be: EiCancelEvent used by the VTN to call off an event EiRefuseEvent used by the VEN to call off an event As it has evolved, though, Opt now means something else. tc It is the theory that decides what can be observed . - Albert Einstein Toby Considine Chair, OASIS oBIX Technical Committee U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee Facilities Technology Office University of North Carolina Chapel Hill, NC Email: Toby.Considine@ unc.edu Phone: (919)962-9073 http://www.oasis-open.org blog: www.NewDaedalus.com From: Koch, Edward [mailto: [email protected] ] Sent: Monday, July 04, 2011 1:22 PM To: William Cox; [email protected] Cc: Dave Hardin; Bruce Bartell; Rish Ghatikar LBL Subject: RE: [energyinterop] Re: Opt Out (really cancel during an event in progress) Bill, I was very precise in my language and you should read the requirements I listed very literally. I intentionally used the word opt-out as opposed to opt-in. I think the requirements are very straightforward and do not need any elaborate justification. See my inline comments below. Suffice it to say that the functionality described is in use today and is in the OpenADR 1.0 as described. I understand that in ei we have tried to include other requirements and expand the notion of €œOpting € and it has made even the discussion of this topic somewhat complicated, but let €™s not lose sight of the requirements that I listed and make sure that whatever mechanism we use or whatever additional requirements we try to satisfy in ei that what is described in the requirements I listed can be accomplished. I understand if you don €™t think it can get into PR2. On a separate but related topic I €™ve been looking at wip3 of the schemas and the EICreatedEventPayloadType and it looks convoluted with some recursive and redundant attributes. Toby mentioned yesterday that you guys were still working on some payloads. Have you guys completed that work? Thanks -ed Koch From: William Cox [mailto: [email protected] ] Sent: Monday, July 04, 2011 7:12 AM To: [email protected] Cc: Dave Hardin; Ed Koch; Bruce Bartell; Rish Ghatikar LBL Subject: Re: [energyinterop] Re: Opt Out (really cancel during an event in progress) Ed and Rish - Thanks for the explanations. Question number one continues to be is this ESSENTIAL for PR02? I haven't heard a direct response to that, and no pushback. I'll put it on the top work item list (there are a few other things there - I'll be sending a list when I can - but it includes finishing the factoring/conformance work in progress, this, finishing EiResponse values, and the WSDL) One problem has been that the discussion uses the same phrase, opt out, for two very different things - withdrawing from a specific event in progress (or scheduled/committed) and stating availability for future events. The way forward is more clear without that overloading. Separating out the notification may be beneficial for (on first blush) small deployments, but where stochastic techniques are used, I would think it's less useful. So to implement this functionality I see several important goals: (a) notify the VTN that the VEN will no longer respond in the current event (b) isolate that notification from forward planning (to address the VTN watching the Avail all the time problem) >ED €“ this is not a goal or objective in and of itself, but a consequence of the fact that currently specific events can €™t be opted out of until they are initiated. I will point out that there has been discussions of the notion of opting out of the €œnext event € but that is different than what we have been describing. (c) trigger any penalties or charges >ED €“ the consequences of opting out are potentially wide ad varied. (d) not applied beyond this narrow situation as it doesn't generalize well >ED €“ I don €™t know what this statement means. Are you implying that opting out of an event is only relevant with the context of ( c )? That is clearly not true and even if it were I don €™t understand what the relevance is for the solution we come up with. I see the VEN action as akin to a delayed the event fails with respect to me notice, but that is a confusing model for typical business interactions where you commit and then follow through (or not). For example, when you buy block power you can't back out in the middle of delivery; if you don't accept there may be penalties, and if you don't need all of it you transact in a market to sell your excess. Back to my steps: FIRST step is justification of need - to understand real business requirements and/or regulatory requirements for this behavior. Is this discussed in the Phase 2 NAESB requirements? Informal use cases; is it in the NAESB requirements? SECOND step if there is justification is for the TC to decide whether to support this behavior I don't see doing this before Wednesday, hence my repeated question is this essential for PR02? I don't think that it is, and a slapdash approach while other actual errors are nearly corrected seems more of a problem than not doing it. THIRD step is to determine the solution. See below for my thoughts. We've speculated along those lines, but we can't skip step two. FOURTH step is to determine the release. Given the timing of steps 1..3, I think this is post PR02. And if it's not picked up by the TC it's on the list of possible items post 1.0 I've heard no pushback on this. I think this is a work item post PR02 (short list above) FIFTH step is to do the work. Back to my original three suggestions: I'd see using either (a) EiCancelEvent sent by the VEN, rather than the VTN. This has the defect that the event is not canceled, only that particular VTN's paricipation. (b) EiCreatedEvent could be called up to twice; if first called by the VEN with accept, then it could be called once more with Failure. This seems odd, and pushes the behavior into a re-used operation that confuses the flow. (c) Create a new function, VEN is service consumer, VTN is service provider, say EiStopEvent, that would indicate the VEN's decision to no longer abide by its commitment in accepting the event in the first place. I'm more strongly attracted to (c) , which I'm now thinking is the simplest and meets the goals. ED> I disagree. I think that b is simplest because in my opinion we have already established that the EiCreatedEvent needs to contain attributes that specify how the VEN will respond to the event and this obviously falls into that category. I admit that having to send another EiCreatedEvent if the opt status changes may seem a bit odd, but it €™s actually how we currently do it in OpenADR 1.0. My gut feeling is that even if you create a new service it will look a lot like the EICreatedEvent when everything is said and done. I €™ll also point out that in the very early implementations of OpenADR 1.0 we supported a separate service for opting out like you are suggesting in option c and there was multiple independent requests from the device vendors that we put it in the response like you are suggesting in option b above. This notion and justification was listed in my requirements. Notes interleaved below. Thanks! bill -- William Cox Email: [email protected] Web: http://www.CoxSoftwareArchitects.com +1 862 485 3696 mobile +1 908 277 3460 fax On 7/3/11 11:09 PM, Koch, Edward wrote: Not sure what the exact issue is or if what I am about to say is going to add anything to what has already been said in the numerous email threads, but here is my input. There are the following requirements: (1) The VEN be able to opt out of a particular event and they notify the VTN of the fact that they want to opt out of that event. As Rish has stated this is important for the VTN to know and yes since they are opting out of a specific event then the VEN won €™t notify the VTN that it is opting out until after the event is initiated. Note that I used the word €œinitiated € and not €œstarted €. Initiated means that an event is queued up and the VEN has been notified of that fact. Typically this is if the highest value with DR programs which have long notification periods so the VTN will know well in advance of the event actually starting that the VEN is opting out. This says that you can't back out of a commitment you don't know about, suggesting that an EventID and ActiveInterval/prep interval need to be known before backing out >ED €“ of course (2) The VEN be able to opt out of an event via the CreatedEvent response that it sends back to the VTN when it receives the EIEvent from the VTN. This specifically allows the device to opt out of an event without having to implement the more complex Opt service. This wasn €™t in the original OpenADR 1.0 spec, but enough vendors asked for it that we added it. In the 1a schemas and spec? >ED €“ yes In OpenADR 1.0 a VEN could opt out of a specific event either through the Opt service or through the CreatedEvent response operation. If we support the opting out of a specific event through the CreatedEvent response then we probably don €™t need to also support it in the Opt service. This is where I thought we were going last week so I didn €™t respond. Yes, that's where I was going. Opt is a clumsy mechanism for this, and requires monitoring by the VTN of the current opt state for each VEN. That's what I want to avoid. This suggests a specific notification outside the EiOpt service. Thanks, -ed Koch From: Girish Ghatikar [ mailto:[email protected] ] Sent: Sunday, July 03, 2011 6:23 PM To: William Cox Cc: EITC; Bruce Bartell Subject: [energyinterop] Re: Opt Out (really cancel during an event in progress) Hi Bill, Within the context of VEN opting out and the function of notification to VTN is one aspect of it. While the ability to opt-out of an active event by VEN in itself a significant need (with any subsequent penalties), the notification serves the purpose of providing immediate alert to VTN to find alternate resources to meet the reduced response from a VTN or a set of VTNs. See note above - I think that when you're in stochastic analysis territory, this notification is much less useful. In OpenADR, there are following is the language for additional opt-out conditions to the participant (VEN): A participant may choose to opt € out or override participating in DR events. The participant does this by using the OptOutState entity to set up one or more conditions within the DRAS that define when the participant will not participate in a DR event. The OptOutState may have the following attributes: · Which DR programs the conditions apply to. If not specified, it defaults to all programs. · Which DRAS Clients the conditions apply to. If not specified, it defaults to all DRAS Clients. · Which DR event the conditions apply to. If not specified, it defaults to all DR events. · A schedule which defines when the conditions apply. The facility manager opts out of the DR program. At any time, the facility manager can opt € out of the DR program on the DRAS. When in an opt € out condition, DR events are not propagated to the DRAS Client. The opt € out can be either for the entire program or a single event or a specific event € mode (e.g. normal, moderate, high) Thanks, -Rish On Sat, Jul 2, 2011 at 9:14 PM, William Cox < [email protected] > wrote: Please take a look at http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-423 . I've just added extensive comments. I think this is post PR02, and maybe post 1.0. The only function served appears to be notification to the VTN to not expect further response/generation from the particular VEN with respect to a particular event, and only after the event ActiveInterval has been entered. Since a VEN can always stop performing, and incur any relevant penalties, the notification seems the only thing of value here. Thoughts? Thanks! bill -- William Cox Email: [email protected] Web: http://www.CoxSoftwareArchitects.com +1 862 485 3696 mobile +1 908 277 3460 fax -- Rish Ghatikar Lawrence Berkeley National Laboratory 1 Cyclotron Road, MS: 90-3111, Berkeley, CA 94720 [email protected] +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]. -- Rish Ghatikar Lawrence Berkeley National Laboratory 1 Cyclotron Road, MS: 90-3111, Berkeley, CA 94720 [email protected] +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].