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] Scope questions for discussion


And I would like to remind everyone that ebMS 2.0 is a mature OASIS standard for data exchange transport and has a very mature stable of interoperable implementations -- Drummond Certified interoperable if I may shamelessly plug.  Beyond that, ebMS 3.0 is more firmly based on WS-* standards that is really one of the only standards group that is addressing WS mult-hop scenarios, which I think may be pertinent to nodal smart grid distribution designs.  ebMS 3.0 also has a streamlined profile called AS4, which is targeted at simplified, interoperable WS data exchanges.

Derek N LaSalle wrote:
82ADB140D56CC34B83B6B3F4A982B70006353384E2@EMASC214VS01.exchad.jpmchase.net" type="cite">
We leverage ws-addressing w/ ebMS user and signal message body components. This allows piggy-backing of signal messages with user messages which optimizes flow utilization especially when combined w/ box-carring (message groups). WS-* adherence provides the benefit of widespread development tools and software services support from commercial vendors and open source. This includes W-SecureConversation for authentication and authorization.

Regards,
Derek LaSalle
Head of Information Architecture
JP Morgan Investment Bank


From: Sila Kiliccote <skiliccote@lbl.gov>
To: Old, Bob <bob.old@siemens.com>
Cc: Energy Interop <energyinterop@lists.oasis-open.org>; Considine, Toby (Campus Services IT) <Toby.Considine@unc.edu>; Ed Cazalet <ed@cazalet.com>; Larry Lackey <llackey@tibco.com>; Songkakul, Pornsak <pornsak.songkakul@siemens.com>
Sent: Wed Feb 03 10:23:17 2010
Subject: Re: [energyinterop] Scope questions for discussion

Bob,
Great comments, thanks!
I agree with everything on A - thanks for the emergency/reliability signal reminder. I talk about this all the time, don't I? I think they are very similar and the only difference may be the issue/notification time.
On B - this is a meter access issue. I am assuming it also depends on a contract outside of the b2g interface. If the meter access is a standard communication (with security), any entity that the customer allows can have access. As far as double dipping - yes the priority and communication has to happen at the level where your kWs are valued (so still not at the b2g interface)
On C - Not at the B2G interface but a good thing to think about on the utility side.
On D - looks like more discussion is needed.

Sila
On 2/3/2010 6:52 AM, Old, Bob wrote:
A9B77DA2F009964B8C55C575F04A9CB8057BC011@USLZU102MSX.ww017.siemens.net" type="cite">

Hi Sila,

 

I would like to add:

 

A.      In the Grid to Building direction:

a.       I think there should be separate Emergency/Reliability signals, not just price.  The signal should be clear and not blurred by mapping to a price.

b.      Especially with DER becoming more prevalent, upcoming maintenance/outage management events need to be announced.  Buildings would like to know when to turn on the backup generators.  And the construction crews would appreciate the building make the circuits safe for them.

c.       A unique Program Identifier is required because the building/meter/feeder might be involved in a number of programs with a number of different service providers.

d.      Other, program specific information is required.  As usual, Ed homes in to the heart of it in the Curtailment program example, the baseline.

 

 

B.      In the Building to Grid direction:

a.       To whom does the custodian allow access to the data, for how long, which items, and when each item was effective?  And where should the custodian send the report of who accessed what and when of my data.   I don’t want to be promiscuous with my data—I wouldn’t want burglars to identify when my facility will be closed for Founder’s Day.

b.      Since I may want to sell curtailment to more than one CSP, I will have to permit both to access the same data.  I leave it up to them to figure out a way to make sure I’m not selling the same curtailment to two CSPs.  Though if someone can come up with a clear mechanism, I would love to hear it.

 

C.      Trusted custodian of the data:

a.       Electricity Distribution Entity – the one who has the data, now.  Is always affected by the load on the distribution infrastructure.  Is the natural monopoly the will likely always be regulated by politicians.

b.      Root Certificate Authority-like entities.  Used to authenticating.  Verisign doesn’t give me warm fuzzies, though.

c.       Others you suggest.

 

D.      And while I was blathering away here, I see Toby’s assessment of customer forecasts.  I like it.  What’s it worth to ya?  Perhaps it’s a clause in the Program.

 

So much for fun, back to work,

B.O.  February 3, 2010

 

Robert Old

Siemens Industry, Inc.

Building Technologies

1000 Deerfield Pkwy.

Buffalo Grove, IL 60089-4513

Tel.: +1 (847) 941-5623

Skype: bobold2

bob.old@siemens.com

www.siemens.com

 

From: Larry Lackey [mailto:llackey@tibco.com]
Sent: Tuesday, February 02, 2010 11:23 PM
To: Sila Kiliccote; Ed Cazalet
Cc: Considine, Toby (Campus Services IT); Energy Interop
Subject: RE: [energyinterop] Scope questions for discussion

 

Great start, Sila. To the list I’d suggest adding the building or facility’s bid/ask price for consumption/DER over the relevant time period(s).

 

This could, and probably should, be iterative with the “Grid”, which might be multiple institutions, providing forward costs for different intervals and buildings responding.

 

 

Larry

 


From: Sila Kiliccote [mailto:skiliccote@lbl.gov]
Sent: Tuesday, February 02, 2010 9:30 PM
To: Ed Cazalet
Cc: Considine, Toby (Campus Services IT); Energy Interop
Subject: Re: [energyinterop] Scope questions for discussion

 

If the grid has the historical data from each facility plus weather data from each location, it can generate forecasts for each building as well as the aggragate. The building's prediction is an fyi for the grid  This happens in the grod between utilities and ISOs all the time  sort of like a check/balance  but may not be necessary if not trusted. 

 

Sila 


On Feb 2, 2010, at 8:18 PM, Ed Cazalet <ed@cazalet.com> wrote:

The grid usually forecasts load in the aggregate.  What is the building forecast for?  If it is a baseline for a DR program, then who should be responsible for the forecast?  The customer should not do it, because of the incentive to bias the forecast.

 

Edward G. Cazalet, Ph.D.

101 First Street, Suite 552

Los Altos, CA 94022

650-949-5274

cell: 408-621-2772

ed@cazalet.com

www.cazalet.com

 

From: Considine, Toby (Campus Services IT) [mailto:Toby.Considine@unc.edu]
Sent: Tuesday, February 02, 2010 7:31 PM
To: Energy Interop
Subject: RE: [energyinterop] Scope questions for discussion

 

Traditionally, building load management has been crude, and aggregated in certain large time granules. Industrial sites, however, have had strong incentives to manage peaks.

 

As operating safety margins get smaller, it may become increasingly important to manage peaks aggressively, even within the neighborhood or even home. Is some sort of detailed peak /load shape of interest in the new world? What about power factors? Is the forward and backward reporting of curves rather than points of measurement the future of smart metering?

 

tc

 


"If flies are allowed to vote, how meaningful would a poll on what to have for dinner be, and what would be on the menu?" -  Unknown


Toby Considine

Chair, OASIS oBIX Technical Committee
Co-Chair, OASIS Technical Advisory Board
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: Sila Kiliccote [mailto:skiliccote@lbl.gov]
Sent: Tuesday, February 02, 2010 6:09 PM
To: Energy Interop
Subject: [energyinterop] Scope questions for discussion

 

All,

David Holmberg and I had a great conversation today on the scope of EI (which will hopefully feed into section under discussion). I’d like to open up some of my ideas and get your feedback before I propose a few paragraphs for the scope section.

 I’d like to look at the scope from a B2G interface point of view and the questions I suggest we try to answer are:

1.      What information do the buildings need from the electricity grid?

2.      What information does the electricity grid need from the buildings?

 Buildings’ need from the Grid:
-         Electricity prices (various forms such as absolute, relative, level, etc)
-         DR contract parameters – excluding direct load control: A contract can have the following parameters:

   -         Issue time, start time, end time

-         Within the start time and end time there may be a request from the grid for load reduction (%, absolute, relative, etc) (or load increase - when there is too much generation)

       -    Power quality (Do we care how “good” the power we get from the Grid? Probably! What are the indicators to be communicated to a building?
 -    Location of the resources needed

 Grid’s need from buildings:

-         Measured (current, historical) demand
-         Predicted demand
-         Available DR (over next 24 hrs?, 1 week?)
 -   Location identifier (meter, address, grid  location indicator?)

 I welcome your comments. All of the above assumes that the meter is the demarcation point. And just to add, the expansion of this to DER can be again categorized as on the utility side and on the building side but should be a super set.

 
Sila

 

This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.



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