1 OASIS Energy Interoperation TC Meeting Notes
2 February 16, 2011
4 Meeting Attendees: (Sorted by Company Name)
6 NOTE: Text chats during meeting: http://webconf.soaphub.org/conf/room/EnergyInterop.
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.
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
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
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
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
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
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
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.