Re: [energyinterop] Re: "Opt Out" (really cancel during an event in prog

Subject: Re: [energyinterop] Re: "Opt Out" (really cancel during an event in progress)

-Rish

On Mon, Jul 4, 2011 at 7:12 AM, William Cox <wtcox@coxsoftwarearchitects.com> wrote:

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)
(c) trigger any penalties or charges
(d) not applied beyond this narrow situation as it doesn't generalize well

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.

Notes interleaved below.

Thanks!

bill
--

William Cox
Email: wtcox@CoxSoftwareArchitects.com
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

(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?

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:gghatikar@lbl.gov]
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 <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.

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: wtcox@CoxSoftwareArchitects.com
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
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].

--
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].

energyinterop message