OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

energyinterop message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [energyinterop] RE: Initial Port of OpenADR to EnergyInterop


Toby,

 

As I understand it, BACnet WS was designed precisely for the case of some outside entity that wants to read data from or write data to a BAS. Isn’t that what OpenADR is about? BWS is agnostic to what protocol is in the building, so it is certainly not meant to be tied to a BACnet system and locked behind the ESI. I guess you could argue that it is useful for one BAS over here to talk across the Internet to another BAS over there, bypassing BACnet-over-the-Internet and LON vs. BACnet headaches. But that was not the primary intent. Craig, Sharon—correct me if I am wrong. I’ll also copy Dave Robin on this question, hope that’s OK. I think this is an important issue. Is OpenADR (son of) supposed to address energy interoperation between buildings and the SG? If BWS and oBIX are out of scope, what is in scope for that?

 

As for ESI interfaces---Market entities (passing price and what else?), grid operation entities (for grid reliability signals), and Aggregators (or building operators) passing on these signals (or some modified signals) to buildings they manage. Is there feedback to the market entities? I can see grid operation enitities requesting info on availability of load shed, generation, and storage, on weather, and what else? I can see building managers/ aggregators requesting similar info perhaps at different levels of detail. I can see a verification aspect—requesting sub-system electric usage data post-event perhaps, with independent verification from the utility meter. Or maybe that isn’t verification—just a post-event data analysis service to help in future grid event planning.

 

David

 

From: Considine, Toby (Campus Services IT) [mailto:Toby.Considine@unc.edu]
Sent: Tuesday, July 21, 2009 11:22 AM
To: Holmberg, David; 'Dinges, Sharon'; 'Edward Koch'; 'energyinterop@lists.oasis-open.org'
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:david.holmberg@nist.gov]
Sent: Tuesday, July 21, 2009 10:45 AM
To: Dinges, Sharon; Considine, Toby (Campus Services IT); Edward Koch; energyinterop@lists.oasis-open.org
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:sdinges@trane.com]
Sent: Tuesday, July 21, 2009 9:14 AM
To: Considine, Toby (Campus Services IT); Edward Koch; energyinterop@lists.oasis-open.org
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:Toby.Considine@unc.edu]
Sent: Monday, July 20, 2009 20:40
To: 'Edward Koch'; 'energyinterop@lists.oasis-open.org'
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:ed@akuacom.com]
Sent: Monday, July 20, 2009 8:41 PM
To: Considine, Toby (Campus Services IT); 'energyinterop@lists.oasis-open.org'
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..



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]