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


Hi Sila,

 

Thanks for the feedback.  Let me clarify a couple of things.

 

In B, I have no illusions that utilities are going to let me dig around in their meters.  Actually, I imagine the usage data stored in there will need to be adjusted and validated and estimated eight ways from Sunday. (Nothing is as simple as it seems.)  I figure the DR Program will identify exactly what they mean by Energy Usage information and the definition is probably regulated by the PUCs.

 

And though the new meters I hear about will do autorun when a USB thumb drive is plugged in, I don’t think they have the horsepower to do the database manipulations and reporting that I need.  The current backhaul is also probably too slow; table-talk in ZigBee indicated that they chose Elliptic Curve Cryptography because the keys were small.  And perhaps less defensible but just as compelling is that many utilities think leased-line backhaul is more secure, will not share their communication means, and will not use a shared public Internet.  This surfaced at one of the Security sessions during ConnectivityWeek last year.  When people challenged them (well, just me,) Gunther had to step in and assert that an assessment would be made and the right thing would be done.  Personally, I don’t think leased-lines for security reasons are worth any extra cost.

 

I agree, the exchanges between the custodian of my meter data and the third party, energy service providers/DR Program administrators wouldn’t go through my B2G interface.  But I need to communicate B2G the granting and revocation of access to my private data among the custodian and service providers in their Domain.  Mainly I wanted to raise the issue because my proposed solution to the problem of preserving the options of the building operator to participate in multiple programs requires third party service providers to take action.  Really, they are forced to.  What’s to stop various Service Providers from setting up different DRAS servers on the Internet and enrolling customers?

 

On C, since I view the meter data from my facilities as “my” data, I expect to have control over it.  I note that the Release 1.0 of the NIST Framework document has pushed Privacy issues into the future, but the 2nd public draft of the security NISTR 7628 discusses preliminary results of a high-level Privacy Impact Assessment document which seem to be heading in the right direction.  The down side is that apparently much of the privacy regulations are on a state by state basis, if they are within the scope of the public utility commissions at all.  But I still expect to control my data across a B2G interface from the Customer Domain to the Service Provider Domain.

 

Best,

B.O.  February 4, 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: Sila Kiliccote [mailto:skiliccote@lbl.gov]
Sent: Wednesday, February 03, 2010 9:23 AM
To: Old, Bob
Cc: Energy Interop; Considine, Toby (Campus Services IT); Ed Cazalet; Larry Lackey; Songkakul, Pornsak
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:

Hi Sila,

 

I would like to add:

 

In the Grid to Building direction:

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.

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.

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.

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

 

 

In the Building to Grid direction:

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.

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.

 

Trusted custodian of the data:

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.

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

Others you suggest.

 

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:

What information do the buildings need from the electricity grid?

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

 



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