[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Fwd: notes EI working meeting - Feb. 17, 2010]
|
All, 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. Thanks! Rish -------- Original Message --------
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. -Anne --
|
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 namespace: * 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. edc: 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) rish: 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: conformance rish: 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: actors rish: most of naesb had already inputs from openadr, so may be one and the same line 702: rish: 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 rish: 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. Minutes: 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]