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: [Fwd: notes EI working meeting - Feb. 17, 2010]


Notes from today's EI TC working meeting (not official TC meeting) -- Thanks to Anne!

Some of the chat notes are also attached. If you've any comments/questions, please send it to the TC list.

We focused on three topics:
1. Update on NAESB process and voting of PAP09 requirements specification by their Task Force.
2. Discussion on WD 04 (this is the most recent version posted on the EI site)
3. Brief summary of UCAIug activities and OpenADR harmonization with CIM and SEP for C&I and residential customers.


-------- Original Message --------
Subject: notes from today's EI meeting
Date: Wed, 17 Feb 2010 09:06:33 -0800
From: Anne Hendry <ahendry@pacbell.net>
To: GGhatikar@lbl.gov

Hi Rish,

Here are the notes I took for today's meeting.  I lost a bit of the 
latter part of Ed's longer comments but hopefully you'll be able to 
catch where the notes diverge from reality and use them primarily to 
fill in.

I included the chat output in the latter part of the notes file.


Rish Ghatikar
Lawrence Berkeley National Laboratory
1 Cyclotron Road, MS: 90-3111, Berkeley, CA 94720
GGhatikar@lbl.gov | +1 510.486.6768 | +1 510.486.4089 [fax]

This email is intended for the addressee only and may contain confidential information and should not be copied without permission. If you are not the intended recipient, please contact the sender as soon as possible and delete the email from computer[s].
 Anne Hendry
 David C. Wilson (DCW)
 Ed Cazalet
 Ed Koch
 Jeremy J. Roberts
 Phil Davis
 Rish Ghatikar
 Sila Kiliccote
 maybe others ...

one other announcement:
naesb activities through ucaiug
edk: summarize voting for naesb for integrated document
tomorrow (naesb meetings 2pm cst) will be going through retail use cases
public comment period before exec revveiw
also tomorrow what next phase is
want to do some additional effort on rquiremnts side
need mor effort in data requirements; use cases ok, but nto enough time spent on data reqs
3parts: frameworkd, wholesale, retail
naesb and oasis working to contribute to ei; after that still tbd
official ratification aprox 30 days comments then to exec committee for approval
on ucaiug, also focused on data reguirements
also related; and 
2-3month timeline to have significatn portion of work done
loose ratification process, but can anticipate in that time substantial content
ed will send link to documents

rish: most recent section from .5 doc; any topics considered important to cover today?
no comments
phil: no comments

areas where toby had questions (highlighted areas

* using one namespace no issues; will handle versioning

* line 385 (actors)
naesb actors document is separate -- available now, agreed upon
just go to naesb to find that

* line 387 (market interactions)
financial business processes; must take closer look; derek lasalle
keep open for discussion

* line 410
on dr verification
edc: main challenge is sthat the baseline is not contracted for, it's forecasted
need to forecast what the baseline would have been after dr action
need to make distinction -- in favor of moving in direction of baselines
 that are contracted for even if that is a ways out
then make allowance for contracted as well
in california (see paper posted by 3 market monitors -- cal iso, etc)
basic idea is that in regulated env would be given sertain amount of power
at prescribed price, then pay for it, then you pay a regulated rate
in open market, could do business just on real-time prices,
or could go buy forward contract to hedge that
at that point, would know what was contracted for and baseline
and could apply dr and know what you're getting

phild: sessentially 3 baselines: performance below baseline based on past days perf;
baseline independent of performance; then agreement to drop below current.
edc: so what is baseline underlying: forecasted or contracted for?
if contracted, then have clear incentives.
can't manipulate the baseline except at your own expense.

would baseline be residential basedon region?
then for commercial normally contracted?
way to think about it: moving priciing (15 min, hour) here don't need baseline
because no forward pricing; here, if want to curtail, just raise prices
alternatively, if that is viewed as too risky or want forward info on consupmtion
then get forward pricing and that woudl serve as your baseline for any real consumption
your retail contacts -- in transition moving from a still vertically integrated utiliy
implementing real time pricing, woudl take yoru portfolio of generators, allocate some
of that to retail customers, and for each customer class, figure out a baseline
-- each hour of that month they'd have a price based on allocated baseline,
if over consumption, then price at real time
authors of 'build your own baseline'?
can buy any amount at .12 per hour, but nto required to do it.
edc: many ways to implement
edc: email report to group (is also posted on the site)

basically had separte system from own meters and system assessed baseline
calculated how much shed happened in a dr day and then did settlement based on that
but then if going into dr verification making it part of ei dr standard signals,
opens up lots of signals -- area we should be looking inot? or part of separeate program?
to include semantics at the open dr

sila (communication going in and out -- could not capture well)
supply side language very diff from generation side issues
any time demand side aprticipated, need to know what is avaikolbe, how much
that kind of info is important to get from a building and grid
tied very closely to generation; 
agree with ed

rish: thought it was important to have som einfo from demand side in signals
sila: yes, demand side schedule, just like generation schedule, just like facility aggregation
will write up and send to group
rish: yes, for discussion on building <-> grid

line 514:
not many -- place holders now;
came up in ucaiug meeting
is a push from lbl side to start working on openadr framework for conformance
are there minimum requiremetns, etc.  will be looking at that
will be working at lbl to come up with document to describe at higher level
what conformacne would be; market conformance subcommittee (at ucaiug)
openade, openhan -- they want to start definign requirements for conformance
summary may lead to more discussion and thoughts;more disucssion in next few weeks

line 673:
rish: most of naesb had already inputs from openadr, so may be one and the same

line 702:
need to consider somantics offered by FIX and iso 20022;
need to use less exceptional terminology

edc: probably emix will be working on that
rish: yes, so let's follow up there

rish: supply side demand events
line 738 supply side elements
rish: document ed forawarded to gorup has informaiton on this
edk: uca follows spec devleopment process (a users gorup developing best practices,
not a standards group) uca group for CIM and coming out of TC57
thi si s refered to as system requiremenst specificcation, 
meanging this is looking at data requirements -- what date needs to be handled
uca has spent most of it's effort supporting naesb
next is SRS activity; in uca some openhan, some ami activity, but no consolidated
effrot to look at what at dr resource is and how to react whith those from a data modeling
across all ..
so open adr task force are uniquely positioned to do some harmonoization
to make sure on utilty etneriprise side is a consolidated view
how that dr resource is ineteracted with -- the lower level detail
because all dr resoruces share common attributes
this diagram depicts this scope
this committee here at oasis is looking at interaction bewteen utilty and building,
so somewhat complimentarty
will take what is coming out of both sides and integrate
hopefully from some CIM model that is extended (or already exists)

?L Cim has 2 parts: form the substation to the utility, and then additionally
(possibly not impoemented) also something within industrial facitlites wehre
you do load control, but scaled down
are we only trying to address what is on the outside of the facility?

EdK: yes, looking at direct load control; could potentially touch on some of these things
openadr not dealing with direct load control -- not looking at internal facility interaction

2 areas: inside facility and outside -- demarkation
oasis is looking inside consumer owned interface -- are we crossing that boundary
w.r.t. CIM?

edK:you mean the uca effort?  yes.
within uca efort, if there are models requireing direct load control, then we will
cover that as well

rish: so in furtuer can anticipate one model w/o direct load control, and one with
edk: one might be SEP model, not necessarily CIM 
notion of moedling at enterpise level of utilty and then profiles that can coem out of those models
a profile dicatatiin a certain interaction, and then a sep profile, etc.
main thing is on enterspie sied, a set of data models and attributes which can properily
describe and model the data attributes correctly
more about how to model and vocabulary sued to moedl

rish: looking at diagram ...
public network and ami network
what is the rationale behind not having public network as interface
edk: just a representation of way utilityes are thinking of likely scenarios
can use ami networks for cni as well; just representational that says 'likely'
doean't have to be case -- many utilities won't have ami
don't take it as carved in stone


chat notes:

Jeremy J. Roberts: ..... Energy Interoperation TC Workshop Meeting .....

Date:  Wednesday, 17 February 2010
Time:  11:00am - 13:00pm EST

Event Description:
Regular Workshop/Technical Meeting of the OASIS Energy Interoperation TC This is an informal workshop; notes and participation are recorded but attendance does not count toward voting rights.

Conference numbers:
+1-866-740-1260 (US toll-free number) or
+1-303-248-0285 (US and non-US toll number).
Access code 4866768.

anonymous morphed into Phil Davis

Rish Ghatikar: Agenda:
Further discussion toward writing down sections for the specification.


Rish Ghatikar: Ed: NAESB meeting to vote retail DR use cases

Rish Ghatikar: tomorrow on Feb. 18.

Rish Ghatikar: tomorrow's meeting will also include what the next phase will be. what are data requirements?

Rish Ghatikar: AnnH: what form will those requirements be when they come out?

Rish Ghatikar: EK: It'a big document with one framework document and two documents, one each for retail and wholesale

Rish Ghatikar: the documents will go to public review period after voted tomorrow.

Rish Ghatikar: the UCA report will be focusing on data requrements as well

Rish Ghatikar: AnnH: Timeline for process?

Rish Ghatikar: EK: As far as NAESB - has to go through Exec. comm for approval

Rish Ghatikar: approx a month for NAESB process

Rish Ghatikar: 2-3 month timeline for significant work.

Rish Ghatikar: UCA has loose ratification process -

Rish Ghatikar: Specification WD 05 most recent:

Rish Ghatikar: 221 Here of course is a big question. Do we have a single namespace for all of Energy Interop, or do we have
222 one for each of the major areas?

Rish Ghatikar: DWilson: I posed that question - I mean if we should consolidate into one name space. Once concern was some of the conversion utilities would handle that.

Rish Ghatikar: Ed: That was a concern a year ago - I don't see any reason why we should not

Rish Ghatikar: There are some concern with maintaining issues with multiple name spaces.

Rish Ghatikar: DWilson: Is that a strong limitation?

Rish Ghatikar: EK Don't think it's a strong limitation - will double check.

Rish Ghatikar: Unless, it's an issue, we move forward with one namespace.

Rish Ghatikar: Rish: Any technical consideration

Rish Ghatikar: DWilson: Have proper documentation of using multiple namespaces - using multiple name spaces means, we're using a kW values - make sure use the right kW value in all name sapecs

Rish Ghatikar: AnnH: One consideration is to consider the future versions.

Rish Ghatikar: So that the version be contained in the URL

Rish Ghatikar: DWilson: It's contained in the namespace already.

Rish Ghatikar: 2.1 Actors
264 The standard list of actors will be based upon the NAESB list of standard actors for DR and DER

Rish Ghatikar: The actors were voted couple of weeks ago - there is agreed upon

Rish Ghatikar: 298 2.3 Market Interactions
299 Is there a normative definitions of the atomic market interactions from the ISO20022 world?

David C. Wilson (DCW): The current proposed namespace is http://docs.oasis-open.org/ns/energyinterop/energyinterop-201001 .

Rish Ghatikar: 303 2.4.1 Demand Response Verification
304 Area needs considerable discussion
305 Demand Response is an odd beast. It is focused on change, not performance. The thinking is: we cant
306 really prove what energy you would or would not have used, so instead we will focus on did you perform
307 specific acts irrespective of whether or not any particular amount of energy is used.

Rish Ghatikar: EdC: Submitted couple of papers - baseline is forecasted.

Rish Ghatikar: EdC: Strong in moving torward baseline that are contracted for.

Rish Ghatikar: EdC: Contracted baseline is basically - in a regulated env. you're given certain kW - you can pay for it or sell it - a regulated market.

Rish Ghatikar: EdC: In unregulated market - buy a forward contract that will allow you to hedge that.

Rish Ghatikar: PhilD: There are essentially 3 kinds of baseline - based on past-days performance

Rish Ghatikar: EdC: When it's contracted - one can't manipulate the baseline - unless at your expense.

Rish Ghatikar: JeremyR: What about baseline for residential?

Rish Ghatikar: EdC: Refer to the paper I had posted - longer conversation.

Rish Ghatikar: EdC: Think of it as moving to RT pricing - in that market there is no need for a baseline.

Rish Ghatikar: EdC: Concept of Build your own baseline.

Rish Ghatikar: Rish: Do we need to emphasize on M&V?

Rish Ghatikar: Sila: the supply side and demand side equation.

Rish Ghatikar: SK: What's available from the building to grid?

Rish Ghatikar: SK: Baseline is an issue for non-price response.

Rish Ghatikar: SK: Given a baseline, some-side of demand-side schedule.

Rish Ghatikar: Rish: Disussion on UCA summary document sent by EdK

Rish Ghatikar: EdK: the SRS - system requuirements specs.

Rish Ghatikar: EdK: SRS first step is looking at use case development

Rish Ghatikar: Ed K: From utility side there is a consolidated view of DR resources and how it interacts with OpenADR/SEP/etc.

Rish Ghatikar: EdK: One of the objectives of how this harmonization will be.

Rish Ghatikar: EdK: Looking at CIM and how this relates to others.

Rish Ghatikar: JR: CIM has two parts to it - 1 substation to facility demarkation - additionally have something implemented within industrial facility for direct load control - are we addressing only outside.

Rish Ghatikar: EdK: Clearly we will be looking at DLC models.

Rish Ghatikar: EdK: Current incarnation of OpenADR does not do DLC

Phil Davis: Sorry, have to jump on another call

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