[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [energyinterop] Squeezing the Message
OK, I have been misunderstanding the purpose of the sequence in the EiEventScheduleType which currently looks like: <xs:sequence> <xs:element name="eventActivePeriod" type="eitc:IntervalType"/> <xs:element name="eventNotificationPeriod" type="eitc:IntervalType" minOccurs="1"/> <xs:element name="eventRampUpPeriod" type="eitc:IntervalType" minOccurs="1"/> <xs:element name="eventRecoveryPeriod" type="eitc:IntervalType" minOccurs="1"/> </xs:sequence> Thanks to Ed K for explaining it to me last night. - The ActivePeriod is the duration for the Event. If it is a three hour event then presumably the sum of the Durations in any signals will also be 3 hours. If a contract permits/requires 15 hours of DR a [Year], then 3 hours counts against that 15 hours. If payment is a lump sum per hour, then the Active Period determines that 3 hours are involved. It is unclear if an attachment is required for an event in today’s markets. An attachment carrying an EMIX message could be important in tomorrow’s markets. - Ramp Up and Recovery are Durations that help define the event. o The primary purpose is to define the ActivePeriod [contract]. If the Ramp up interval starts when the active period starts, then it is part of the interval. If it starts before then it is outside of the interval. Let’s posit a 15 minute Ramp on that 3 hour ActivePeriod that is 5 MW response beginning at 2:00. If the ActivePeriod and the Ramp Start at the same time, then the Ramp starts at 2:00 and the peak response (5MW) does not need to be reached until 2:15.; the event is paid for beginning at 2:00. Alternately, if the 15 minute response must before the ActivePeriod, the VEN is expected to reach Peak Response at event start, at 2:00. o In a similar manner, Recovery defines whether the Recovery is inside or outside the event. It is unclear whether there is any expectation that the building not be recovered for [15 minute], i.e., if the building hold off and not slam the grid at event end. I am assuming that the Recovery is not for that purpose… - NotificationPeriod is a bit odd. *My* impulse is that it is expressed as an EMIX Term, probably at the market level, and is not event-based. The counter-argument is that it si a “performance hint” to the VEN. “During the Notification Period a VEN the Building may start pre-cooling”. Presumably this has some interactions the RampUp if the RampUp precedes the ActivePeriod. There is also a notion that the Event is a document that may be prepared in advance, and stored/forwarded/polled at some non-deterministic schedule. If so, that document might be prepared before the Notification period, but not in the possession of the VEN by that time. I have a feeling that some things are still occult, perhaps because M&V is outside of scope. At some level, these seem easily computable and thereby redundant. Speculating on some rational contracts that could be created, but are not in scope might explain why they are needed. For example, it is probably rational to establish Baselines prior to the Notification Period. Certainly, saving energy over the pre-cooling period is no great feat… If there is a potential dispute, it is useful to state that directly… Choices: - A full fledged EMIX Ramp curve. The start time designates whatever interval it wants as the Event Start time. The same starting [gluon] also starts each of the Signals. Requires some designator for whether the Recovery is in or outside the event. - A single full-fledged interval. We define additional xcal-parameters (w/I EI) for rampupUpDuration and rampDownDuration. These Durations can be positive or negative, as needed. - We could use / overload the Ws-Calendar Tolerance Value which in some sense expresses the same as the ramp-ups and ramp downs. <xs:complexType name="ToleranceValueType" mixed="false"> <xs:annotation> <xs:documentation xml:lang="en"> A tolerance value is a set of durations which indicate the allowed tolerance for the indicated value, e.g. startafter=PT5M indicates that 5 minutes late is acceptable. </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="startbefore" type="xcal:DurationValueType" minOccurs="0" maxOccurs="1"/> <xs:element name="startafter" type="xcal:DurationValueType" minOccurs="0" maxOccurs="1"/> <xs:element name="endbefore" type="xcal:DurationValueType" minOccurs="0" maxOccurs="1"/> <xs:element name="endafter" type="xcal:DurationValueType" minOccurs="0" maxOccurs="1"/> <xs:element name="durationlong" type="xcal:DurationValueType" minOccurs="0" maxOccurs="1"/> <xs:element name="durationshort" type="xcal:DurationValueType" minOccurs="0" maxOccurs="1"/> <xs:element name="precision" type="xcal:DurationValueType" minOccurs="0" maxOccurs="1"/> </xs:sequence> </xs:complexType> StartBefore/StartAfter and EndBefore/EndAfter arguably express the same concepts as the Ramps, as long as the Ramps do not include EMIX or Resource payloads. Example: Active Period with Tolerance to express Ramps as allowed 10 minutes at begin/end of Active Period. <xcal:interval> <xcal:properties> <xcal:uid> <xcal:text>ActivePeriod</xcal:text> </xcal:uid> <xcal:dtstart> <xcal:date-time>2011-05-28T13:00:00</xcal:date-time> </xcal:dtstart> <xcal:duration> <xcal:duration>PT3H</xcal:duration> </xcal:duration> <xcal:tolerance> <xcal:tolerate> <xcal:startAfter>PT10M</xcal:startbefore> <xcal:endBeforer>PT10M</xcal:startafter> </xcal:tolerate> </xcal:tolerance> </xcal:properties> </xcal:interval> Example: Active Period with Duration derived types to express Ramps. We would need to decide whether the negative Duration on the Ramp means before or after the Start. Same with the Recovery. Interesting semantic question. –Duration could subtract from the active period or not, or Duration could be expressed on a time axis (Positive advances into the future) which requires opposite treatment at the beginning and end. <xcal:interval> <xcal:properties> <xcal:uid> <xcal:text>ActivePeriod</xcal:text> </xcal:uid> <xcal:dtstart> <xcal:date-time>2011-05-28T13:00:00</xcal:date-time> </xcal:dtstart> <xcal:duration> <xcal:duration>PT3H</xcal:duration> </xcal:duration> <ei:rampUp> <xcal:duration>PT-30M</xcal:duration> </xcal:duration> <ei:recovery> <xcal:duration>PT1HM</xcal:duration> </xcal:duration> </xcal:properties> </xcal:interval> Notification could be handled as is the duration-derived properties, if we want to get parsimonious—unless it is necessary to get a start time on the Notification. An ongoing question is what is the potential Attachment to the Active Period. - If it is anything simple, we can attach an EMIX product Description. - If SPC201 specifies a Sequence, does EI invoke that sequence? If the single Interval above is in a vcalendar container (which it currently is), then a [currently imaginary] SPC201 sequence could be referenced as a sibling in that same vcalendar (or elsewhere, as the UIDs can be URIs). There is no inheritance defined for siblings. It could be a Parent with inheritance defined. We don’t have to decide today, when there is no SPC201. Of course, we can also still a trio if intervals in a sequence FF/FS and SF / SS are sufficient to express the relationships just fine, and let a pre-defined sequence be in place, invoked by a remote reference with only a start-date, duration, and reference to the activePeriod. That is less like what is communicated today, but might have some good legs on it. I can generate all 3 kinds of artifacts for a full EventSchedule this afternoon of folks want… Comments or suggestions? tc "He who fights with monsters should look to it that he himself does not become a monster, and if you stare long into an abyss, the abyss also stares into you." - Fredrich Nietzche
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]