[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 don’t want to get too
far off track with this discussion since obviously the primary focus of the TC
is on semantic models and interaction specifications, but when it comes to interfaces
my personal recommendation would be that the OASIS TC work on common internet
based interfaces such as simple SOAP and REST and that we collaborate with
other organizations to integrate our semantic models with their “grid
side” interfaces. I don’t think we have to worry too much
about playing favorites. It’ll be hard enough convincing other
organizations to take this course and devote the requisite effort. I think
that candidates include: BACnet (commercial building) OPC (industrial) SEP (residential) 61850 (Utility operations) Note that by listing these
organizations I am not implying that they tightly integrate the models created
by this TC with their “inside the facility” control protocols since
we all agree that what happens in the facility stays in the facility, but each
of the organizations listed above have a notion of what it means to interface
to systems outside the facility (e.g. BACnet web services) over some wider area
network such as the internet. That is where we should be collaborating. If we were somehow able to collaborate
with the above organizations and agree to a common semantic model for transporting
son of OpenADR messages over their grid side interfaces then that would
be quite an accomplishment toward creating an industry wide standard for a common
DR signal. -ed koch From: Michel Kohanim
[mailto:michel@universal-devices.com] 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]