It all depends on how dumb the device is. For instance, one
cannot expect a regular switch/relay to be intelligent enough to understand
contracts, pricing, and responses. I have to rephrase: one could expect such a
functionality but the question is how much are we willing to pay for such an
intelligent device to perform such a dumb job (turn something on/off).
I think it’s the job of ESI/EMS/EMCS/Gateway/BAS to handle
contracts/pricing and figure out how to respond intelligently and accurately.
With kind regards,
********************************
Michel
Kohanim, C.E.O
Universal
Devices, Inc.
(p)
818.631.0333
(f)
818.708.0755
http://www.universal-devices.com
********************************
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
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
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
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.