OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

energyinterop message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: Notification vs. Request vs. Order

Title: Notification vs. Request vs. Order



I think your comments are consistent with my email.  The way we are dealing with this in the current specification is that the program itself has certain implied contractual obligations and semantics that are associated with the information that is being sent as part of the signal and thus may not be explicitly represented in the signal.  We may want to add additional information to the signal, but only if we think that it will in some way affect the response of whatever entity is consuming the signal.  I think that some of this may be flushed out as part of the price definition work that is going on.


It is also important to note in the current specification that there are many constraints and parameters associated with programs that can be configured and queried, but are not explicitly sent as part of the DR signal every time it is sent.  Take a look at the “ProgramConstraint” entities for examples of what I am talking about.



-ed koch



From: Wilson, David C (St. Paul) [mailto:DavidCWilson@trane.com]
Sent: Monday, September 14, 2009 6: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”.



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



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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]