RE: [energyinterop] Notification vs. Request vs. Order

["Wilson, David C (St. Paul)" <DavidCWilson@trane.com>]

Thanks to everyone commenting on my email on this subject.  I've been
reading all the replies with great interest.

I want to build on some of the comments. My thoughts follow quotes from
some of the emails (mine prefixed "DCW:").

M. Kohanim >> without the use-cases [...] these messages may change
dramatically depending on the actors.

DCW: Good point, see Gale's last comment below. 

Gale Horst >> regulatory and contractual obligations should not be tied
to the messages but should be enabled and supportable by the messages.

DCW: Agreed.  The messages should be support the different commercial
agreements.

Gale Horst >> I have a difficulty separating a notification from a
request.  If you don't intend to motivate a response, why would you send
a notice?  

DCW:  The small distinction I tried to communicate is that the ESI needs
to support a building response that differentiates between "I got your
message" and "This is my reaction to your message".  

Toby >> What is the interaction to tell [relatively dumb device] the
contract #[must respond] ids in place, so device knows that a mandatory
response is required tomorrow. Worrying about this is what keeps me from
a simple price & notification only model...

DCW: I think to be widely adopted the by commercial buildings, the ESI
should include a schedule-less option.  The utility / OpenADR "Program
Notifier" should not expect that the building will be able to schedule
the event.  

Bob Old >> Your example could refer to a Direct Load Control command to
a Programmable Communicating Thermostat in a residential application.
Or it could be a curtailment request to a large building.  

DCW:  To both Bob & Toby's point with dumb devices.  Maybe one option is
that the Notifier sends a count down. "Event in T -27 hours"...."Event
in T -8 hours"..."Event now".  This allows a dumb device to simply be
configured for the amount of lead time it needs to begin responding.

Gale >> If peer-to-peer is desired, then the DRAS would represent the
end use node and be considered the "peer" that responds to the "order".

DCW: Wow! That was a very helpful statement!  I have been struggling
with reconciling the DRAS design and the NIST interface list.  I've been
playing "pin the DRAS on the roadmap" without much mental success (NIST
Interface diagram link below).  Mostly I was trying to determine how far
the DRAS penetrated the customer domain.  I didn't consider that maybe
the entire DRAS is inside the customer domain.  Maybe the Grid
Operations to Customer (NIST terms) interface is the Utility to DRAS
interface (OpenADR terms). For example the "Utility Program Notifier
creates and initiates Base Interruptible Program Event" use case shown
in OpenADR figure D12 (see URL below). 

NIST Interface diagram
http://www.oasis-open.org/apps/org/workgroup/energyinterop/document.php?
document_id=34213

OpenADR Base Interruptible Program Use Case Picture (Figure D12)
http://www.oasis-open.org/apps/org/workgroup/energyinterop/document.php?
document_id=34212

=======

Again, thanks to everyone for the lively discussion!  I will attempt to
carry on the Actors / Roles conversation in a separate thread.

Regards,
Dave

Office: +1.651.407.4168
Mobile: +1.612.741.2759
Email: davidcwilson@trane.com


-----Original Message-----
From: Old, Bob [mailto:bob.old@siemens.com] 
Sent: Tuesday, September 15, 2009 8:09 AM
To: Considine, Toby (Campus Services IT);
energyinterop@lists.oasis-open.org
Subject: RE: [energyinterop] Notification vs. Request vs. Order

K.I.S.S. is good, but things can only be so simple.  Devices need to be
smart enough to handle the contemplated programs.  
 
Your example could refer to a Direct Load Control command to a
Programmable Communicating Thermostat in a residential application.  Or
it could be a curtailment request to a large building.  
 
For a PCT, the command might include a program ID, an event ID, event
type (increase setpoint on AC), a start time and duration, and perhaps a
priority of importance over other possible programs.  The PCT needs to
acknowledge, non-repudiably (if that's a word,)  that it agrees to
respond as required by the program.  Perhaps it already knows that it is
exempt from particular responses and it sends that response (can't turn
off invalid's air conditioning completely.)  
 
Perhaps an hour ahead of the scheduled event the resident decides not to
participate because they're hosting a child's birthday party and are
willing to pay any price to keep the kids happy.  They push a button on
the PCT which signals the utility and opts-out of that event.
 
For a C&I consumer, the command might include a utility/aggregator ID,
program ID, and event ID, event type (request for curtailment,) baseline
below which you must curtail in order to get credit, a start time and
duration, and perhaps a priority of importance over other possible
programs.  The ESI acknowledges, non-repudiably, and perhaps includes an
estimate of the amount of demand below the baseline that can be
curtailed.  After the event, the utility/aggregator and the ESI both
acquire the meter data relevent to the event.  The utility/aggregator
uses it for settlement of the transaction, the ESI uses it to verify the
settlement and perhaps refine it's model of building behavior.
 
Undoubtably, the contract between the building operator and the
utility/aggregator specifies the terms and conditions for opting out of
an agreemement.
 
I'm not sure things can be made simple, due to the large scale of the
application.  I've always heard that if you want to do Electric
Utilities applications, you have to be able to do at least a million.
 
Best,
B.O.  September 15, 2009
--
Robert Old, System Architecture, bob.old@siemens.com
Siemens Building Technologies, Inc., HVAC Products
1000 Deerfield Pkwy., Buffalo Grove, IL 60089-4513  USA
Phone: +1(847)941-5623, Skype: bobold2


________________________________

From: Considine, Toby (Campus Services IT)
[mailto:Toby.Considine@unc.edu]
Sent: Mon 9/14/2009 7:13 PM
To: 'energyinterop@lists.oasis-open.org'
Subject: RE: [energyinterop] Notification vs. Request vs. Order



I'm with Gale

 

If I have a contract with you that says "I may respond", then you need
to notify me.

If I have a contract that "I must respond" then you need to notify me.

Notification is notification.

 

But I do have a question. What is the interaction to tell [relatively
dumb device] the contract #[must respond] ids in place, so device knows
that a manadatory response is required tomorrow. Worrying about this is
what keeps me from a simple price & notification only model...

 

tc

 

________________________________

"A man should never be ashamed to own that he has been in the wrong,
which is but saying ... that he is wiser today than yesterday." --
Jonathan Swift

________________________________

Toby Considine

Chair, OASIS oBIX TC
Facilities Technology Office
University of North Carolina
Chapel Hill, NC

  

Email: Toby.Considine@ unc.edu <mailto:Toby.Considine@fac.unc.edu> 
Phone: (919)962-9073 

http://www.oasis-open.org 

blog: www.NewDaedalus.com

 

 

From: Horst, Gale [mailto:ghorst@epri.com] 
Sent: Monday, September 14, 2009 11:45 AM
To: Wilson, David C (St. Paul); energyinterop@lists.oasis-open.org
Subject: RE: [energyinterop] Notification vs. Request vs. Order

 

Team:

 

Those are interesting comments.  I don't recall if we have discussed
this before.  But it begs questions about whether there are smart grid
messages in this space that are tied to contractual obligations as
described by the "Orders" classification Dave mentions.

 

My first impulse is that regulatory and contractual obligations should
not be tied to the messages but should be enabled and supportable by the
messages.  I think this discussion may fall under the header of project
scope. 

 

Although I see the difference, I have a difficulty separating  a
notification from a request.  If you don't intend to motivate a
response, why would you send a notice?  If the message is an "Order",
the real difference is that you are not only wanting a grid-impacting
change, you are counting on it.  But it would seem that OpenADR  DRAS
should be able to accommodate this difference in a way that enables a
clean one-to-many message rather than peer-to-peer.  If peer-to-peer is
desired, then the DRAS would represent the end use node and be
considered the "peer" that responds to the "order".

 

My 2-cents,

Gale

 

 

Gale R. Horst

Electric Power Research Institute (EPRI) 
Office: 865-218-8078
ghorst@epri.com 

________________________________

From: Wilson, David C (St. Paul) [mailto:DavidCWilson@trane.com] 
Sent: Monday, September 14, 2009 9:16 AM
To: energyinterop@lists.oasis-open.org
Subject: [energyinterop] Notification vs. Request vs. Order

 

Hi EI folks,

In reflecting on Ed Koch's presentation last week, I start to think
about the semantics of "Notifications", "Requests", and "Orders".
Especially in the context of normal business transactions (Purchase
Orders, Requests for Quotes, Price Notifications.

I think part of what Ed was saying (and Ed I'd like to hear your
thoughts) is that the presence of price information in the ESI messages
don't identify the nature (i.e. sender's intent) of the message.  I
think it would be good if the ESI message/information is clearly
identified as "Notifications", "Requests", or "Orders".  Here is how I
think of them:

From the sender's perspective:

Notifications: Here is some information.  I want to be sure you received
it because that is my responsibility.  I don't care what you do with it
(I might care what the majority of recipients do).

Requests: I'd like you to do XYZ.  Please let me know if you will do it
or that you did it and maybe what the results are.

Orders:  We agreed that I could tell you to do XYZ.  I may want you to
confirm that you will and/or have.  I might only care to learn after the
fact that you did not do XYZ because I need to punish you.  I may or may
not be able to do anything with the knowledge that you plan to defy our
agreement.

Part of the difficulty I have in reconciling the CA OpenADR and the
concept of the ESI is that the paradigm in my head for the DRAS is one
system (Server, Client).  I imagine the ESI "interface" to be between
two systems ("Peer to Peer").  Not sure if that makes much of a
difference at the Type level.

I am advocating that the ESI we define have clear options for
distinguishing between "Notifications", "Requests", and "Orders".

Thoughts?

Dave

David Wilson

Enterprise Solutions Portfolio Manager

Trane Commercial Systems

Ingersoll Rand

Office: +1.651.407.4168

Mobile: +1.612.741.2759

Email: davidcwilson@trane.com <mailto:JSmith@trane.com> 

www.trane.com <http://www.trane.com/> 

 

The information contained in this message is privileged and intended
only for the recipients named. If the reader is not a representative of
the intended recipient, any review, dissemination or copying of this
message or the information it contains is prohibited. If you have
received this message in error, please immediately notify the sender,
and delete the original message and attachments.


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 


The information contained in this message is privileged and intended only for the recipients named. If the reader is not a representative of the intended recipient, any review, dissemination or copying of this message or the information it contains is prohibited. If you have received this message in error, please immediately notify the sender, and delete the original message and attachment..