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.
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.
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
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