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

From
Considine, Toby (Campus Services IT) <>
Date
2009-07-21T15:21:40+00:00
ID
Thread
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..