[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [energyinterop] RE: Initial Port of OpenADR to EnergyInterop
Hi Ed, Right on the money. I fully
agree with your all your 3 points with one caveat on the 3rd: are we
saying that we are going to pick an interface as the base and then refine
it to meet our requirements? If so, should the model already be part of some standards
or we just pick one that has the most “market” penetration? If we
choose one with the most market penetration, then, aren’t we providing an
added advantage to the company(ies) behind it? With kind regards, ******************************** Michel Kohanim,
C.E.O Universal
Devices, Inc. (p)
818.631.0333 (f)
818.708.0755 http://www.universal-devices.com ******************************** From: Edward Koch
[mailto:ed@akuacom.com] 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:michel@universal-devices.com] 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, Sharon, 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 EMS). David From: Dinges, Sharon
[mailto:sdinges@trane.com] Toby, I believe this is a fair assessment. The interactions between
the EMS and the external ESI are more appropriately communicated using XML and
web services. Then, at the EMS level, the systems would communicate using BACnet,
LonWorks, OPC, HAN, DALI, etc. Regards, Sharon 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
EMS. It certainly will be in any industrial environment… 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: Edward Koch
[mailto:ed@akuacom.com] 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]