[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [energyinterop] Re: "Opt Out" (really cancel during an event in progress)
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:Toby.Considine@unc.edu] 5.4 Naming of Services and OperationsThe 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
From: Girish Ghatikar [mailto:gghatikar@lbl.gov] 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) <Toby.Considine@unc.edu> 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
From: Koch, Edward [mailto:Edward.Koch@Honeywell.com] 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:wtcox@CoxSoftwareArchitects.com] Ed and Rish - >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.
>ED – the consequences of opting out are potentially wide ad varied.
>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.
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.
We've speculated along those lines, but we can't skip step two.
I've heard no pushback on this. I think this is a work item post PR02 (short list above)
I'd see using either 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.
William Cox
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 (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. Thanks, -ed Koch From: Girish Ghatikar [mailto:gghatikar@lbl.gov] 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 <wtcox@coxsoftwarearchitects.com> 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. --
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]