Document Sample
OASIS Powered By Docstoc
					1    OASIS Energy Interoperation TC Meeting Notes
2    October 19, 2011
4    Meeting Attendees: (Sorted by Member Last Name)

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
 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.
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
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)
24   2. Approve Minutes:
25   Later

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?

 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.

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.

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.
201   4 Planning for the coming week:
202   Not covered
204   5. Adjourn:
205   Meeting adjourned around 9:35 AM PDT.


Shared By: