1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
OASIS Energy Interoperation TC Meeting Notes
August 03, 2011
Meeting Attendees: (Sorted by Company Name)
Legend:
EK
JP
BC
AH
RG
AS
JR
CT
Ed Koch
Joshua Philips
Bill Cox
Anne Hendry
Girish Ghatikar
Aaron Snyder
Jeremy Roberts
Chuck Thomas (Observe)
DH
BO
BB
JG
SK
TC
PD
EC
David Holmberg
Bob Old
Bruce Bartell
Gerald (Jerry) Gray
Sila Kiliccote
Toby Considine
Phil Davis
Ed Cazalet
NOTE: Text chats during meeting: http://webconf.soaphub.org/conf/room/EnergyInterop.
Full attendance is available online if maintained: Go to the event notice page on OASIS EI TC website then click
“Track Attendance” at the top.
Agenda:
1. Call to Order and Roll Call
2. Approve Minutes (as available)
3. Randomization in Events
4. Task List Progress
5. JIRA issues
6. Factoring Issues
7. Adjourn
Minutes:
1. Call to Order and Roll Call:
BC: Call to order – roll call – we’ve quorum
Voting Members: 11 of 14 (78%) (Used for quorum calculation)
2. Approve Minutes:
None
3. Randomization in Events:
BC: Background - randomization request in WS-Calendar. TC said not appropriate
TC: Blurring the response. Using "randomization" - NOT the goal. The goal is smoothing the response curve. As we
1
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
move out of the realm of talking to device drivers to business services.
BC: as we get to business issues - price...
PD: Sequencing - may make more sense to business people – Logic that controls the startup and sequencing.
BC: 61850 - no distribution
PD: randomization important to people - AC turn on when they choose, predictable random event. Talk about
service restoration or bringing up a large facility. Can't do that
TC: Sequencing - requested to ramp, rather than randomizes – Other assets, home and service recovery where you
want randomization in one-way or another. May want both specified. Would the WS-Calendar people like it? They
thought it was very muddy. Start 5 minutes early, or 7 minutes late.
TC: Not clear - what would it mean if you can start 5 early, 7 late, random factor of 12 minutes.
EK: Broad use cases - two.
EK: Scenarios in point-to-point with all resources - VTN/VEN interactions, can do explicit sequencing; tell it to
start/stop at very specific time. In that case where we do that level of granularity in control
EK: Use case where "randomization" is relevant - "broadcast" where everyone receives the same signal. Need
some sort of randomization to prevent start/stop at the same time. Have tolerance parameter - can specify
interval around the start/end times. How spec in EI? Do we want to use a conformance statement (if tolerance is
used at start of event, implication is that it's randomization) OR add a "randomize parameter" - may be able to
specify more around that tolerance interval
TC: (Thought for later, do we need to add a ramp command. A large VEN [industrial facility] with a single resource
could be able to take down local distribution all by itself. It can be requested to ramp slowly.
DH: Limiting demand spikes – Step/ramp function from lower to higher. For broadcast - turn on at the same time
(when devices get juice back). IN that case need something LIKE a randomization function for those small devices
where "the utility has some control" and other cases where you need to mandate a ramp function - say come on in
a ramp function that allows that in addition.
BB: Ramp definition is already there - "randomize/distribute" is new
DH: Don't send different intervals to all VENs – is there some standard ramp?
EK: The ramp notions in a market context express capabilities is not part of any schema for messaging that tries to
define behavior. Not too much in the market context - capabilities - not what the resource is "supposed to do"
EK: Doesn't require too complex a solution. Additional attribute to specify behavior in this interval identified
(tolerance interval) can expand to rep both randomization and a ramping behavior. Would NOT go beyond that.
DH: Agree with Ed.
TC: Randomization type already specified, can imagine different devices say - I am supposed to do some kind of
step back, others say "I'm a big guy, know I'm supposed to ramp slowly". If "blur" is the command, some devices
do randomization, others say "I ramp to do the blur".
EC: A couple of cautions. Quickly shut down - make sure I can turn randomization off from a SO POV. Suppose I
have a SP providing HS storage - quite capable of smoothing any sudden operations out of the many resources. To
the extent you constrain ALL the resources you're sub-optimizing the system
EC: Other resources may compensate for change (BB: Microgrid regulation)
EC: Or a fast response is required. If pre-programmed for random response.
DH: randomization is trying to get a smoother response when we have multiple loads coming online at the same
time (e.g. due to broadcast DR event)
BB: “Rampetization” - goal is to smooth response. NOT merely to randomize. How do we tell things to start or stop
in a smooth way?
TC: Existing WS-Calendar - starts tolerance, end tolerance, also event length – If you started 3 minutes late run for
exactly and hour. All are optional parameters. Meet for blurring at head, end of event. What's left is a spec of
exactly how you want to use that flexibility.
TC: Might want to say, "Do the beginning/ignore the end"
BB: Multiple ways to achieve smoothing EK: If objective is sequencing - have it now - 1:1. Can't sequence without 1:1. Don't need the spec interval if you do
that.
TC: Sequencing by the VTN that gives sequenced behavior of the VENs.
EK: Already handle it.
EK: In the context of the other two: "smoothing" - randomization, ramping. Should conflate those.
2
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
EK: IF NOT broadcasting send (as case 1
BC: That's where this really needs to be handled. If broadcasting as signal don't know whether randomization or
ramping, conflate both into a single attribute. Interoperability by what receives the signal.
TC: coherent discussion of approach. Will be a place where whatever we do will stick in the craw of nonparticipants (in the TC). The conversation needs to be part of a "note"
BB: non-normative appendix - how you do it.
TC: Same chapter belongs in a committee note. Spec by technologist, notes by others.
EC: Another alternative when send broadcast - those on the odd numbered IDs have one start time; even have
another. Express that to a larger set of numbers – Assignment of IDs.
EK: If we take that approach, this attribute belongs in the target section of the spec - specifying something about
the target of the signal.
EK: Belongs in EiEventType for sure – Probably as a property of the active period in conjunction with the tolerance
parameters.
EK: Or along the lines - maybe in addition - about who is supposed to respond with certainty?
TC: EK said a lot of what I was going to say. Perceive an approach in EK's mind, how to express one in the target.
Would EC like to propose on the list how to communicate the alternate approach? Perhaps both needed/allowed
TC: EC's approach nice in some market interactions - blur but have broadcast.
BB: economic - price fuzzy, take advantage of lower price
DH: Target is still group of customers, how you respond
TC: Industrial sites have market rules - mostly by hand/contract, well known to facility EM. No doubt for multiple
decades - when reconnect, have "if you exceed spikes, go up too fast" large penalties. For the big boy - that's
already in the market agreements.
BC: NOTE MarketContext needs this info also?
BB: MarketContext - post 1.0. Want simple communication of desired effect, mechanism per VEN?
4. Task List Progress:
BC: TASKS - finish in 2 weeks
TC: Need to iron out some complexity issues.
TC: Substantial parts need to be done.
BC: Task 2 - finished, express in doc/schemas/model
BB: continuing 3 - some have teams looking.
BB: Examples - 427 proposal to add digital signature - needs to be resolved. 411 - EC not sure I understand.
BB: Under way, need to be sure that all services/ops/payloads have been examined.
Tasks 4-5-6 progresses not finished
BC: 7 started but not finished
Task 8 TC: Waiting for 1 to 7 to finish for stability. One large issue - 4-5-6 - needs clarification soon. What happens
with the multiplicity of VEN with multiple end points - sharing, announcing its resources, is that registration or
enrollment? PICK ONE. Don't care.
BC: 9 dependent on 3
BC: 10 - continuing
BB: 9 - could define WSDL.
BC: ACTION B, GG, BB set up call this week.
TC: Most significant thing - going from enrollment/registration going forward. At that point 9, 8 ready to go –
Enrollment, Register – the big thing in the entire services family.
TC: simple thing, talking about for five weeks now - can we pick one?
BB: get documents posted by Monday - vote next Wednesday.
DH: This is what Enroll means to IRC?
TC: Not sure having read the documents of each, not sure they're internally consistent. Tendencies - one more like
this or that, just muddy.
TC: 6 weeks of scenario after scenario - trying to get strong comments.
TC: Say what you want, not "current suggestions smell funny"
BC: A variety of things, complex for new programmers, and complexity where things run into each other.
BC: A column for things like EMIX/EI that are "like this"
3
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
BC: Do EMIX - smaller.
BC: Market context. Concept - URI, unique, just a string. Just an identifying string/identifier
BC: EMIX Standard Terms that can be assoc with a MarketContext - can associate; use the MC as the key. Multiple
term sets possible. May be set during business hours, outside.
BC: Can express those business rules.
AS: Is this a document that we'll have access to at some point?
BC: EMIX product description - real power market, and context, why say it over and over again. Factoring, contrary
to the way currently in EI
BC: Measurement - 10MW chunks - can express as part of the standard terms.
BC: Granularity - WS-Calendar - state once it's a 10-minute market.
BC: Time Zone in the MarketContext standard terms
BC: Currency - tends to buy in dollars and stays that way
BC: Non-standard terms handling.
BC: X9, X10-13 - features of the standard term set. Response, max times of day, etc
BC: Availability in each term set - during business hours, rst of summer, ...
BC: How handle non-standard terms - both optional in EMIX
BC: Can say once for the entire standard terms or each step.
BC: Side - sometimes if a buyer is asking or seller, means slightly different things.
BC: If seller says need 5 minute response time, then 3 minute doesn't work.
BC: May be not-to-exceed.
BC: NON STANDARD TERM HANDLING – if something not in the market terms - in X14 - must accept, etc.
BC: See spreadsheet – STANDARD TERMS and MARKET CONTEXT IN EMIX
BC: Optional market context and a UID – Two that are just strings – Troublesome to me.
BC: Market name - no semantic content. Not for machine.
BC: CreateDate - if using for anything substantial, desire to not change often. Nice to say using ... if using older one,
look out. Potential CACHE CONTROL
BC: event schedule - in market context. Not sure factored correctly.
BC: envelope contents - good, wich put in EMIX
BC: transactive state - why is that in the market context.
EK: OpenADR ignoring - want optional
BB: Needs to define for those who are not ignoring it.
TC: I1..I7 - why is eventschedule part of market context; all this stuff around is fuzzy in the factoring.
BC: I8..I14 - avail - also has market terms. Are those different from those assoc with the market context? Looks like
standard terms.
BC: I12 - similar
JP: IRC Seconds EK I7 to be optional
BC: I13 transaction name?
BB: Free text - pattern
TC: Suggest I8-10 look like a standard term set
BB: Looks good to me
TC: granularity (I15-17) a lot of overlap - looks an awful like the standard terms for market.
BC: Market rule set. 118-21
BC: In I22 - rule set purpose - part of the market rule set in I19.
ACTION: TC to add reference.
BC: Rule Set Purpose - don't accept anything smaller, greater, must Understand, must Ignore
BC: Not all in eimarketcontext
TC: Blurred and imprecise relationships between them, as not properly normalized. Need to normalize. Could be
clearer, but doing the same things again and again in slightly different ways – Maybe we need to.
BC: I26 - accept/reject/forgo/restrict - restrict not defined. Sounds more like per-event or per event signal. Maybe
a market rule - don’t know
BC: I27 unspecified rule behavior - same as in EMIX.
BC: May be a multiple pen problem.
BC: Strikes me that we could factor away by using the parts that are the same as the EMIX term set, a few things
4
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
left, re-factor to get to s simpler set.
BB: confusing, hard to enter. Use things that are consistent with the locked down EMIX things?
TC: Yes, first simplify to see what the distinctions are, and then decide where the distinctions are necessary.
TC: And if are necessary, clear distinction where things are used.
BB: probably won't have an opportunity after PR03.
DH: If go out after 1.0 very hard to make changes
BB: propose - small group - chairs, TC, EK to move forward on this.
5. JIRA issues:
6. Factoring Issues:
T Editor - delighted at how using JIRA - much clearer, higher probability of putting into the document what's
intended.
[12:24] Bill Cox1: B: You all can move forward from new to open to resolved - put in your solution in the
"Resolution" box. If there's an issue, let the chairs know and we'll work it out with the TC
7. Adjourn:
Bill Cox1: Motion to Adjourn: Toby, lots of seconds, no objection.
5