Get documents about "OASIS
Document Sample
1 OASIS Energy Interoperation TC Meeting Notes
2 October 19, 2011
3
4 Meeting Attendees: (Sorted by Member Last Name)
5
6 Legend:
EK Ed Koch DH David Holmberg
JP Joshua Philips BO Bob Old
BC Bill Cox BB Bruce Bartell
AH Anne Hendry JG Gerald (Jerry) Gray
RG Girish Ghatikar SK Sila Kiliccote
AS Aaron Snyder TC Toby Considine
JR Jeremy Roberts PD Phil Davis
CT Chuck Thomas (Observe) EC Ed Cazalet
7
8 NOTE: Text chats during meeting: http://webconf.soaphub.org/conf/room/EnergyInterop.
9 Full attendance is available online if maintained: Go to the event notice page on OASIS EI TC website then click
10 “Track Attendance” at the top.
11
12 Agenda:
13 1. Call to Order and Roll Call
14 2. Approve Minutes (October 12, 2011): Later
15 3 Progress and Issues leading to Public Review 03
16 4 Planning for the coming week
17 5. Adjourn
18
19 Minutes:
20 1. Call to Order and Roll Call:
21 DH: Call to order and roll call – we have quorum
22 Voting Members: 9 of 10 (90%) (Used for quorum calculation)
23
24 2. Approve Minutes:
25 Later
26
1
27 3 Progress and Issues leading to Public Review 03:
28 BC: Offline discussions for consistency.
29 BC: Overview of status – Specification published WD 31, Schema WIP 3 – have seen everything in that list. TC any
30 issues?
31 TC: Nothing has happened in the chapter one to three – it’s identical. Message composition and services has
32 received some comments.
33 BC: Comments sent to TC?
34 TC: Yes.
35 BC: Send to the list.
36 EC: Sent some comments to chapter e for transaction.
37 TC: One of the standardized options is payload base – common objects for signals, baseline, reports, snaps,
38 delivery, etc.
39 TC: All those things that receive time sequences of a quantity NOTE PROGRAM NOT LEVEL
40 BC: Misleading to levels as programs – any reason to call programs as levels?
41 EK: Must be levels – the notion of programs is going to go away as no one wants.
42 BC: Had extensive guidance on programs and UCAIug and programs seem to be included.
43 EK: Continue to disagree with TCs implementation.
44 EK: The issue is the program structure on the market context – I have sent extensive items why that is a wrong
45 structure.
46 BC: Put the comments together and send them to the list.
47 BC: The interpretation I see is that there are levels with priority for 0 being the least.
48 EK: Problem is that I see the range application.
49 BC: Compelling reason to have levels.
50 EK: Objections for over a year now.
51 Levels - DH, BB, BC, EK, CT, TC, RG - separate discussion.
52 RG: program reappeared because of a comment from the chairs shouldn't go in without TC approval.
53 TC: Had something out there called a "banana" someone looks and says looks like a level looks like a program. The
54 name has changed back and forth but the object has been there since January.
55 RG: We had resolved this in past.
56 BC: let’s take this offline.
57 TC: Restrict streams schema further - used for everything.
58 EK: Streams for everything, everything is called payloads – no more payloads in the schema?
59 BC: Schema has been used as a message payload. The confusion is message payload or stream load. For example,
60 curtailment numbers, baseline payloads.
61 TC: I can name these anything.
62 EC: Going together calling all parties as streams.
63 BC: No, rather than having four different types of calling interaction – Delivering time sequence to for intervals.
64 EC: If I have to deliver a single interval, still use streams?
65 BC: No.
66 TC: Extensive discussion of active period – think got it right.
67 BC: Ask a question on that. What is active interval from fig 7?
68 TC: Active interval from start time to end time (includes a ramp period).
69 BC: The Active Interval: No signal fall outside that period.
70 TC: Spec right now: if there is no specification of an event gluon that changes the signals, then the active interval
71 controls the bounding of the signals.
72 TC: Allows it to create before/after scenarios.
73 BC: so in your facility you can express your pre-cooling, etc. with the same Active interval.
74 TC: Spec right now: if there is no specification of an event gluon that changes the signals, then the active interval
75 controls the bounding of the signals.
76 TC: The Active PERIOD in event - holds a sequence. The normal form of that structure is one interval. Any other
77 intervals are defined in collapsed, duration as properties of the active interval. Normal sequence with gaps, etc,
78 but the EI specification allows a sequence defined normally.
79 BC: and the active interval is one in that sequence?
2
80 TC: Compact form for expressing the multiple intervals.
81 RG: In the active event period, the ramp is explicitly defined in the schema?
82 RG: Don't want to express full sequence. Define property types - x- (so ignored in WS-calendar but processed
83 without change...detailed conformance rules)
84 TC: 1089-1091 Exist as properties on that active interval.
85 RG: type? T: Duration.
86 BC: Active period includes ramp up/in? No.
87 RG: a lot of people do it before/outside...
88 TC: that's expressed. That's how you say it.
89 BC: Ramp up in event - you're free to.
90 TC: Tied to the beginning of the ramp period, not the Active Interval
91 EK: Tie to the start of the active interval - Not tied together - have a common time period.
92 EK: If the ramp up is before the active - just a hint. No spec.
93 EK: If the ramp period is INSIDE the active interval - might have signals or not - but those cases are treated the
94 same.
95 EK: If in the active period can specify exactly what you want; if outside it's a hint. Recovery period has the same
96 structure and mechanics.
97 TC: Requires changes in 917.
98 TC: Editor is so directed.
99 TC: Tolerance above – put the tolerance on the active period.
100 BC: Tolerance is a property of an active period?
101 TC: Yes – used to blur/smooth the event.
102 TC: Put Tolerance as a property of the active period.
103 TC: Skips, who is designated - applied to the whole period.
104 TC: Tolerance - precisely the tolerance from WS-calendar, apply to the period. If start 3 minutes late and end 3
105 minutes late, ...could say blurred.
106 BC: allows for the discussion of smoothing in SGAC and elsewhere.
107 RG: Tolerance - what we use for rebound effect, everything comes back online because of the way buildings work.
108 RG: More applicable at the recovery stage rather than start.
109 BC: Price transitions.
110 TC: turn off is also relevant - effects
111 TC: Tolerance - includes start before, start after, end before, end after – Can express all four cases inside the
112 tolerance.
113 TC: Section 5 is new – started as big bag of definitions.
114 EC: Not complaining about sections – need to be clear on the VTN and VEN interaction as opposed to the entire EI.
115 BC: Party? These are EI definitions. Don’t see any value to create a whole set of terminology for definitions.
116 EC: Will study the suggestion and get back.
117 EK: Characterization of VEN and VTN and the role that they play (don’t remember where) – parties, resources,
118 markets, etc. has some meaning weather they’re VTN or not. If two parties want to interact with each other, need
119 a VEN and VTN to interact.
120 BC: Not necessary, an active party can take a role of VEN or VTN.
121 EK: The VEN and VTN are not themselves used for business and instead take a role for interaction.
122 TC: When a particular party registers as a VEN that may have resources, which are separately addressable.
123 EK: DR resources can be associated with more than a VEN.
124 BC: ACTION: TC take that and clarify.
125 TC: Resource target is new – many times not only in events to express to parties on the other sides – Semantically
126 a significant thing.
127 EK: No group ID needed if there is a group name.
128 TC: Confusion exists. Can’t define them yet – leave both.
129 TC: Figure it out.
130 TC: Since have service location in targets can say everyone on the west side of town.
131 TC: Market Context
132 TC: Application specific -- Something that has nothing to do. An impulse was SEP2, but it's more general.
3
133 BC: If you have info payload - can set up general rules in market context, in a signal, in a report - have hooks to
134 define some payload that makes sense for a particular application.
135 BC: Say what you're doing; give a baseline – Functions for any application specific information in the interaction
136 pattern.
137 BC: All abstract types...develop your own. EI doesn't change.
138 BC: good and clear way to extend without any.
139 ECK WHY us transactive State there.
140 ACTION: Consider the JIRA item that EC will send to TC and BC.
141 TC: Programs: Minimum definitions that are in the program – upper limit, normal value, signal level.
142 EK: Re-hash the earlier comment. Comments related to this section – offline meeting.
143 ACTION: All send comments/definitions for table at line 973.
144 BB: JIRA issue on that - instruction to the VEN on what pseudo generator to use.
145 BC: Wouldn't use uniform because, there are risks associated with it.
146 EK: Mixing apples and oranges – Asking device to continuously vary – Most devices cannot. Ramp if possible.
147 ACTION: BC email to the group just on this.
148 EK: Ramping in aggregate -- over a certain distribution – Differs from asking a specific node.
149 BC: Test Event in sample message headers - it's an event attribute – Also some discussion in message header.
150 ACTION: Move fig 5-4 on active period elements.
151 RG: Tolerate?
152 TC: Raw XML attributes. X-ramps, before we talked in English about it.
153 BC: EI Event structures should be able to address normative and headers are non-normative and should not
154 include the attributes.
155 TC: Monitoring and reporting:
156 AS: couple of things: the way you request a report is now the one that specifies, have IDs. Can even (not yet rep) so
157 if you always have to do report 7 you can say that and never request it again.
158 AS: Use the specifying a bunch of times – Has to be an ID.
159 AS: Granularity. Every five minutes, write down a number every five minutes.
160 AS: Report Back - if five hour every hour
161 AS: Report gluon - so you can say "start 30 minutes before, report for an hour after" - acts as a gluon to include
162 other things that might extend the report.
163 AS: Item Base - measure real voltage or power.
164 AS: An actual report request.
165 BC: Request ID, Specifying ID, and a scheduler – Maybe optionally include the specifying entity.
166 BC: Scheduler: May have an event gluon, a request Report Gluon, or Interval – Can link a given report to an event
167 with a fixed specification.
168 EK: How is it correlated to this?
169 ACTION: BC DOUBLE CHECK THAT information strings are enclosed.
170 BC: Scheduler is confusing – it determines a report schedule.
171 RG: Have set points defined. Is there any reason why set points or response was picked up specifically for
172 regulation-up/down - where do we stop?
173 RG: Are we looking at dimming? Bi-level switching? Are we going to that level?
174 BC: Standardization could do a Steffes Report, but too specific. But want capability.
175 AS: Type or thing or description or unit or multiplier or sign, and define extensibility to say "put it in this form and
176 group as you like" people should be able to understand what it means. I don't have to fill in everything, and put
177 into those buckets. These conform to a structure. Nothing special about what they asked for other than the named
178 item.
179 AS: We could name anything I want to, quantity of books, units pages, use energy Interop to express it.
180 AS: Misunderstanding of what they could compose to get what they need.
181 AS: That's what I got out of working with Toby - only special thing is report type. Everything else
182 TC: SNAPS: Request a snap - the same as a report. Only meaning is "do it at the time designated"
183 TC: If no status dates time do it now.
184 EK: Object to this. Believe that it's factoring interaction patterns in the wrong direction. The way they're structure:
185 two classes of operations.
4
186 One like report spec that set up the reporting caps.
187 EK: At that point the VEN starts measuring, collecting – preparing reports.
188 EK: Those reports can be executed between VEN/VTN as part of the exchange, not setup.
189 EK: Exchange because moved across continuously or periodically or once requested, should be the same object
190 and mechanism.
191 BC: The fact that it's one thing. Not sure if it merits a separate SNAP - request-response versus continuous
192 operation.
193 TC: Agree.
194 TC: Ended up with snap - how to make a stream not have intervals with XML only.
195 TC: one doesn't have the repeating stream.
196 EK: Once specified identity shouldn't have to do it again.
197 EK: Don't even know if it'll work properly.
198 BC: snap is a data point not an interval.
199 EK: have a VTN requesting data from a VEN – Should be the same, sometime span - a collection of points.
200
201 4 Planning for the coming week:
202 Not covered
203
204 5. Adjourn:
205 Meeting adjourned around 9:35 AM PDT.
5
