Next in thread →
Next in month →
Re: [energyinterop] RE: Initial Port of OpenADR to EnergyInterop
I agree with Ed except in one respect: I think we need to use SOAP and web services -- these are the standard inter-domain integration interfaces; REST is used in selected areas but does not allow (e.g.) reasonable composition of fine grained security. Focus on the semantics, as expressed in WSDL and XSD, and it will be widely reusable. Thanks! bill -- William Cox Email: Web: http://www.CoxSoftwareArchitects.com +1 862 485 3696 mobile +1 908 277 3460 fax Edward Koch wrote: 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:] Sent: Tuesday, July 21, 2009 3:08 PM To: 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:] Sent: Tuesday, July 21, 2009 10:31 AM To: 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:] Sent: Tuesday, July 21, 2009 9:29 AM To: Subject: RE: [energyinterop] RE: Initial Port of OpenADR to EnergyInterop 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:] Sent: Tuesday, July 21, 2009 8:22 AM To: 'Holmberg, David'; 'Dinges, Sharon'; 'Edward Koch'; '' Subject: RE: [energyinterop] RE: Initial Port of OpenADR to EnergyInterop 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 Toby Considine Chair, OASIS oBIX TC Facilities Technology Office University of North Carolina Chapel Hill, NC Email: Toby.Considine@ unc.edu Phone: (919)962-9073 http://www.oasis-open.org blog: www.NewDaedalus.com From: Holmberg, David [mailto:] Sent: Tuesday, July 21, 2009 10:45 AM To: Dinges, Sharon; Considine, Toby (Campus Services IT); Edward Koch; Subject: RE: [energyinterop] RE: Initial Port of OpenADR to EnergyInterop 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:] Sent: Tuesday, July 21, 2009 9:14 AM To: Considine, Toby (Campus Services IT); Edward Koch; Subject: RE: [energyinterop] RE: Initial Port of OpenADR to EnergyInterop 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:] Sent: Monday, July 20, 2009 20:40 To: 'Edward Koch'; '' Subject: [energyinterop] RE: Initial Port of OpenADR to EnergyInterop 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 Toby Considine Chair, OASIS oBIX TC Facilities Technology Office University of North Carolina Chapel Hill, NC Email: Toby.Considine@ unc.edu Phone: (919)962-9073 http://www.oasis-open.org blog: www.NewDaedalus.com From: Edward Koch [mailto:] Sent: Monday, July 20, 2009 8:41 PM To: Considine, Toby (Campus Services IT); '' Subject: RE: Initial Port of OpenADR to EnergyInterop 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..
Next in thread →
Next in month →