Document Sample
OASIS Powered By Docstoc
					 1   OASIS Energy Interoperation TC Meeting Notes
 2   February 16, 2011
 4   Meeting Attendees: (Sorted by Company Name)

 6   NOTE: Text chats during meeting:
 7   Full attendance is available online if maintained: Go to the event notice page on OASIS EI TC website then click
 8   “Track Attendance” at the top.
10   Agenda:
11   1. Call to Order
12   2. Roll Call
13   3. Approve Minutes of February 02, 2011
15   4. Issue discussion by teams (Dave Holmberg)
16   5. Issue ENERGYINTEROP-237 and how to accomplish (EMIX artifact in EiEvent payload)
17   6. Adjourn
19   Minutes:
20   1. Call to Order
21   DH: Call to order
23   2. Roll Call
24   Roll call – We have quorum.
25   Voting Members: 9 of 12 (75%) (Used for quorum calculation)
27   3. Approve Minutes: February 02, 2011
28   PD: move to approve minutes, EL seconds – minutes approved.
30   4. Issue discussion by teams
31   5. Issue ENERGYINTEROP-237 and how to accomplish (EMIX artifact in EiEvent payload)
32   DH: Needs to have some discussion on Bruce's submissions on UCAIug / IRC - Discussion some time in the next few
33   days
34   TC: Who is interested: Edgardo / Bruce / Phil / EdK / Bill
35   TC: Bruce to coordinate
36   EL: where are we on meeting needs of IRC. Needs chance to review by end of week, may have more comments,
37   additional concerns, or moving in right direction
38   DH: Profiles: Where do we stand?
39   BC: Ed and Bill - offline - profile comments.
40   BC: Any comments? Can't be perfect...
41   EC - submitted comments on profiles. (See above)

42   DH: Ed, you'd proposed possible two other profiles - IRC (don't know whether their DR programs are part of
43   OpenADR 1.0), and addressed bidding into IRC markets.
44   EC: in note - that TEMIX be distinguished from transactive – Many flavors of the latter word.
45   EC: IRC - DR programs are part of OpenADR or separate. IRC should be separate profile. Should address bidding
46   into [ISO/IRC] markets should be another profile.
47   EC TEMIX is restricted for good reason.
48   (EC and DH): TEMIX is not every Transactive profile. We need a TEMIX profile. Do we need a transactive profile?
49   EL: Err on the side - separate profile – get it right
50   EL: Think we need another profile. Who do I work with?
51   BC: IRC profile is the whole thing. Restrictive profiles OpenADR (little TEMIX), TEMIX (limited events (TC: and
52   programs), and a third...
53   BC: Commitment - EK - deeper dive on profile, for next meeting
54   EK: Will commit to putting together OpenADR services – need to more fully define.
55   EK: may not be able to specify the exact things, but how ... would be used.
56   EK: Personal straw man first cut
57   DH: TEMIX?
58   EC: TEMIX profile - well defined within the TEMIX profile; some restrictions on what would/would not use out of
59   EMIX. E.g. "block power without ramps" as an example.
60   EC: draft of service list for TEMIX profile was in the email, eliminated one or two as unnecessary.
61   EC: TEMIX restricted profile, block power w/o ramps, draft of services in TEMIX profile – some of them are
62   unnecessary...
63   EC: then highlighted the ones in the TEMIX profile.
64   EC: Another level of that - what in the services do you want to restrict?
65   EC: Is this come down to conformance clauses?
66   BC: As light as hand as possible, do not want to complicate all if EI
67   TC: Does that mean if we have a series of configuration handshakes as a service? Figure out whether something is
68   version 2 or doesn’t know? Imagine new toaster uses TEMIX or OpenADR profile in this area?
69   EK: propose not at this time - implementation details.
70   TC: What language do we use in this town?
71   EK: Down the road
72   TC: Configuration service?
73   EC+EK: suggested interaction patterns for DR, push, pull, etc - could be applied across EI. In/Out Scope
74   EC: DO we need a set of push/pull services? Is it in scope or out of scope?
75   EK: Some of the services are not necessarily for all interaction patterns, event work, augmented with some other
76   interaction patterns.
77   TC: If registration and approval are required, we need a more asynchronous approach. Most of the patterns are
78   more synchronous. Create a thread to do this and wait.
79   BC: Don't want to add a whole bunch of services that accomplish what better programming would. May need
80   support for some devices that *may* not support thread-based architecture.
81   BB: less asynchronous than threaded synchronous; possible for devices that don't support threaded
82   implementations.
83   Some indicate a state of affairs, as in price, or event. These could be push, or pull, or ... Others are tied more to
84   [hand shaking], such as registration.
85   EK: Case by case - don't ask for someone to register him or her – they do and they don’t.
86   DH: EMIX schemas?
87   BC: Close.
88   TC: Almost complete, may lose one or two - normalize.
89   TC: Don't have good examples. Write an app to start spitting out examples. Beyond the complexity of what XML
90   Spy can do with the combined things. Invite anyone else to make another example engine.
91   TC: Schemas / WSDL: Waiting for generator
92   BC: Some interaction diagrams, patterns from various ID, housekeeping task. WSDL as soon as the services lock
93   down, will be time for that, we need the payloads, the patterns, and then services, then the WSDL
94   BC: Team E? DER integration. Sent out email - didn't get feedback on it. Think that the action required is discussion

 95   on whether ... like ELs comments on whether the approach we've taken in EMIX and EI covers the DER cases.
 96   DH: Email on Friday?
 97   DH: Action requirements, discussion, would like to have ELs comments on whether approach in EMIX and EI covers
 98   the DER case.
 99   BC: One of the key things in the EMIX product definitions, the duality of Curtailment and Generation. If you have
100   defined the market products, then you have most of what you have to have for DER integration. Issue (notes w/
101   Edgardo & Bruce) clear that the status and feedback terms were getting confused – Clearly the issue of
102   mechanisms for time-periodic monitoring. Fits with DR and DER. Noted for Bill and Edgardo and Donna P to be set
103   up.
104   BC: EI feedback mechanism already set up in OpenADR question is weather it needs the scope.
105   TC: So this goes to Assets, and feedback
106   BC: Let's make EMIX define.
107   TC: skates into assets. One thing people are looking for feedback on. Could declare out of scope - certain charm. Or
108   in scope, status of what's your thermostat setting fits. If have clarity on assets and status, 4-5 issues
109   TC: last published EMIX. 4 occurrences, 2 are meter assets, 2 are ones where already replaced with resource. Then
110   there's just resources in EMIX. Things that can do things that might affect user or supply.
111   TC: EMIX should NOT have a definition of ASSET.
112   TC: Assets can be generators, or large wind farms, or the smart toaster, what we have...wind farm can be one or
113   1000 propellers.
114   BB: is a resource a collection of assets?
115   TC: Resource is that behind a VEN. *may be more than one* - Target question
116   BC: VEN offers a resource to a market. May be market states in which a resource is incentivized or required to
117   provide granular info about its innards - that's as assets.
118   BC: Definition of asset is a market rule (?)
119   TC: Can't see difference between I'll turn off a big thing if you ask, or I'll turn my thermo down 3 degrees, or I have
120   300 water heaters and will turn off half at a time.
121   BC: All assets reported up.
122   EL: Just pinged Donna - 2pm Fri.
123   EL: Just went through many discussions - similar to the IRC Wholesale - a bunch of the ISOs think of this very
124   differently. Came up with a model that seemed to fit all of them. Happy to discuss
125   TC: Pointed question from an editor - is there a paragraph that I missed that defines asset?
126   EL: Simple. An asset has attributes you can control
128   Resource is a logical set of attributes that you put into a program. Maybe you only enroll "turn off lights" - meaning
129   the resource itself is not controlling the asset. Can be controlled by things that the Resource defines as
130   "controllable"
132   ACTION Sounds like good wording, feed into the Resource/Asset discussion.
133   DH: What does OpenADR need for communication with Assets?
134   BB: Definition? Attributes?
135   DH: What kinds of things you'd talk to an asset about.
136   EK: info that can flow back about assets. Can be sent down
137   EK: W/I UCA, info can flow back from Assets, information down to Assets. Original definition of scope of Assets was
138   to support DLC.
139   BB: Assets - see PR01 line 908
140   EK: OpenADR 1 does not have assets and DLC. From a profile perspective, not deal with DLC at the moment, might
141   be able to not worry about assets at all.
142   BB: I think so.
143   TC: OpenADR 1.0 does not do any DLC. EK thinks we do not need to do direct DLC at all.
144   BB: UCA is a moving target; defer DLC until a later time
145   TC: I was set up as some sort of give me periodic feedback, was *in* OpenADR, from the resource perspective
146   EK: the Feedback in OADR1 was for Resources in our current nomenclature.
147   EK: If defer DLC, don't need to discuss assets in the context of OpenADR. If IRC need, and incorporate, make sure

148   consistent with any potential future use of assets.
149   TC: call outs. A useful comment that if I've set up an Opt-out window in OpenADR that that covers my [owned]
150   assets and resources as well.
151   TC: That's where I got the language "mediated by the resource" - whether opt out window applies.
152   TC: Also hold the precept that there's no direct reach through the ESI.
153   TC: Other piece floating around - storage hints and managing say the ICE energy assets? Feels more like what IRC is
154   reaching for. HINT. Now would be a nice time to store if you want to. How much to you have stored anyway?
155   EK: If we're going to defer DLC, then OpenADR does not need them
156   EC: Deep into storage – Running at all kinds of complexities without much value.
157   EC: Direct storage management has much complexity, little value.
158   EK: avoid complexity because of word asset. Does considering it as a resource will satisfy this notion?
159   EK: The only time is if you need both as part of the same interactions.
160   EK: Physical device is a resource
161   DH: Resource talk to, asset you talk about.
162   DH: Not clear that any needs to happen.
163   TC: reach back to what I said before - aligned with what Ed said – Micro grid offering itself as a resource. If chooses
164   to package to provide granularity
165   BB: So the resource is fundamental. Asset is only a packaging of a set of resources.
166   EL: resource without care for assets worked well for PJM, not for California. Had to expand the model slightly.
167   Speak of something that pertains to DR as an asset or resource
168   BB: discussion - is there need for the term "asset" or the concept "asset"
169   TC: See email discussion this morning - let's not revisit.
170   DH: Does CAISO use both resource and asset and they mean different things?
171   EL: Yes. East coast - tends to be different. Typically fix by consolidating the semantics and having a model that
172   suited both needs.
173   EL: Landed in a good place, where I think we had good synch with OpenADR needs.
174   EK: Confirm - at one time some months back we had some consolidated notion. Can't swear that the conversation
175   is following that now
176   BB: Correction on Bruce's comments - SEP2 was a moving target during development of UCA model. Need to align
177   in the future. There is value in DLC, but may not have value in adding DLC to this draft of EI.
178   AH: Is the issue with terminology or the definitions of the terms - may be something more generic we could use,
179   and not conflict with terms we're already using.
180   TC: Very correct. Asset is very generic, but may have different things, may be in conflict
181   BB: Conflict - everyone knows what an asset is but they're different
182   TC: Two-part process: is there something distinct about an asset WRT research (and how presented)
183   AH: Someone earlier said asset is a way of structuring information/ In English, Asset is not the word I'd come up
184   with. May be more generic English term that would defuse the conflict
185   EL: Good idea in terminology - heard "asset is a package for resource" - that's reversed.
186   TC: internal resources --- package internal
187   BC: Remember recursion - what the VEN manages, may have fine structure inside.
188   DH: Issues on the table - small groups.
189   EC: went through all, presented status. Several are our scope. For those in outline of the example for e.g. dynamic
190   pricing presented in EMIX awaiting the engine to translate into XML. Then handle variations.
191   TC: do you have everything you need?
192   TC: Monkey on my back, not Ed's.
193   BB: meetings set, let's keep focused on those and the email. Asset may be an unnecessary complication.
195   6. Adjourn
196   Next TC meeting: February 23, 2011
197   New and Continuing Action Items: Posted on EI TC Website. Go to the event notice page on OASIS EI TC website
198   then click “Action Items” at the top.


Shared By: