[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
From: Horst, Gale
[mailto:ghorst@epri.com] 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) From: Wilson, David C
(St. Paul) [mailto:DavidCWilson@trane.com] 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 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]