[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [energyinterop] RE: Initial Port of OpenADR to EnergyInterop
I suppose for the purposes of discussion
it helps to have a logical construct one might use for referring to some entity
or a logical grouping of functions. If ESI is playing that role then that is
fine, much like the word DRAS does in the spec. It is intended to represent an
actual instantiation of something then we need to discuss. I have to confess
that I am a little unclear on what the ESI is. I think we are all in agreement that we do
not want to reach into the facility, but as far as the instantiations of interfaces
that get information to the facility I don’t think that questions like BACnet
WS yes/no should be religious discussions that are inherently answered by the
TC charter unless we are going to make a broad statement that we don’t support ANY
interface and ONLY do semantically consistent data models. That is a valid
position, but if the TC’s intention is to specify some sort of interface then I’m
not sure that replacing a gaggle of proposed interfaces with some
meta-interface is the right approach. This is clearly a scoping issue and one
way to resolve it is to ask one simple question: Will there be enough
information contained in the output from this TC for control vendors to build
the appropriate interfaces into their equipment to consume “son of OpenADR”
signals. If the answer to that question is YES then you can not avoid the
issue of specifying interfaces and in my opinion there should be as many
specified as time and market factors allow. If the answer to that question is NO
then we should be clear on who will provide the necessary information on what
interfaces to use so that control vendors can spend the appropriate money and
time to utilize this groups output. Furthermore, in my opinion, questions
about the interfaces for delivering the information should be market driven
questions. I like to use the model of so called “Web 2.0” services to guide my
thinking. When you look at the variety of service providers out there that
provide content that people integrate into their mashups, one thing that you
find is that they tend to support multiple interfaces for getting their
content, be it REST, SOAP, RSS, or even things like RIA libraries for Flex or
Silverlight. The point is that they support multiple means for obtaining the
same content based upon market forces that dictate how many people would like
to receive that content using a particular interface. As absurd as it might
sound, if enough developers wanted to interface to Flickr using BACnet WS then
there would exist a BACnet WS interface for getting photographs. My point is the following: (1) First decide if defining instances of interfaces are within the
scope of the TC. (2) If the answer to (1) is YES then we should base our discussion of
which interfaces to support on market drivers and spend the appropriate time to
support as many different interfaces as makes sense. (3) If the answer to (1) is NO then we should identify who will define
the interface instances (i.e. 61850, SEP, BACnet, all of the above, etc.) and
start collaborating with those organizations. I prefer (3) since it spreads the work
load around and naturally helps identify groups that are willing to adopt the
work. This is what we originally did with the BACnet folks and I think it
worked great. The most important thing is that in the end the interface
instances are defined by someone so that they can be used in the industry. -ed koch From: Michel Kohanim
[mailto: Toby, this is excellent information. Now, my question is: why should we lump
the “interfaces” that the facility uses to interact with the outside world all
into a BOX called ESI? If they are interfaces, they should be treated as such
with appropriate actors … i.e. Market Operations Interface, actors: Market
Operations Service, Facility EMS/Manager, etc. Thank you. ******************************** Michel Kohanim, C.E.O Universal Devices, Inc. (p) 818.631.0333 (f) 818.708.0755 http://www.universal-devices.com ******************************** From: Considine, Toby
(Campus Services IT) [mailto:Toby.Considine@unc.edu] I must say that ESI and what is the ESI
is a matter in a lot of conflict on the smart grid team. I think we get to
define it. As I see it, ESI is the abstraction for
all communications, occluding internal technologies, enforcing security policy,
etc. There are three external interfaces that I know: 1) Market Operations 2) Curtailment 3) Verification 4) Proxy for Direct Control I think energy interoperation is
concerned with (1) and (2). (4) is something else. (3) is one of the
great questions on the draft. What does it mean going forward. I expect we may
spend as much time on determining what if any of (3) is involved. I highlighted
it in the draft for that reason/// As to using BACnet-ws in energyinterop—I
just can’t see it. BACnet-WS was never designed to be in the wild. 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: Holmberg, David
[mailto:david.holmberg@nist.gov] Toby, I believe Ed’s reference to BACnet was
to the use of BACnet web services in the OpenADR spec as one of the options
between DRAS and DRAS Client. Thus BACnet WS is in scope, but otherwise I
agree. So, what is the ESI? In my mind it is an external gateway for access to
the facility network, often owned by the IT dept (if there is one), with the
purpose of firewalling and routing to appropriate box on the inside (like the David From: Dinges, Sharon
[mailto:sdinges@trane.com] Toby, I believe this is a fair
assessment. The interactions between the Then, at the Regards, From:
Considine, Toby (Campus Services IT) [mailto:Toby.Considine@unc.edu] In terms of the smart grid
diagrams, outside communications should be with Energy Services Interface
(ESI), which is something different than the Energy Management System (EMS).
Makers of BACnet, LON, HAN, DALI, et al will each figure out what the middle
layer is. Oft times, the enterprise will be in between the ESI and any BACNET, LON and friends are out of
scope… "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: Enclosed is a pass on the document that
Toby sent out. I mostly tried to answer some of his questions and added
some comments of my own. Here are some general comments: It looked like there is some material
missing at the end. Clearly there needs to be some verbiage
added concerning security requirements. There needs to be some meat added for
the interaction and data models. Perhaps adding in some of the diagrams
from the spec will fulfill this requirement. We need to give some thought to what we
are going to do with the various interfaces, i.e. BACnet versus REST versus
SOAP, etc. -ed koch 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.. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]