FW: Vavailability and Business Schedules

This belongs here, too. We use business schedule esp. in Options and in Constraints…

"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

Toby Considine
TC9, Inc

TC Chair: oBIX & WS-Calendar

TC Editor: EMIX, EnergyInterop

U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee

Email: Toby.Considine@gmail.com
Phone: (919)619-2104

http://www.tcnine.com/
blog: www.NewDaedalus.com

From: Toby Considine [mailto:Toby.Considine@gmail.com]
Sent: Monday, May 30, 2011 7:42 PM
To: energyinterop@lists.oasis-open.org
Subject: Vavailability and Business Schedules

Rish raised the issue of the business schedule in Jira issue ENERGYINTEROP-368 this morning.

http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-368

The business schedule has been replicated in EMIX and, in a slightly different form, into EnergyInterop. The underlying vavailability type in ws-calendar allows the representation of a recurring pattern of schedules over a period that can be either closed or open ended. The vavailability object itself is made up of a set of availability objects, each with a potentially different recurrence. The object below establishes a schedule good for three months (2011-01 – 2011-3) in which there is availability from 9:00 to 11:00 (2 hours) every Monday, Wednesday, and Thursday as well as a schedule for every Friday from 3:00 – 4:00.

<xcal:vavailability xmlns:xs="http://www.w3.org/2001/XMLSchema-instance" xmlns:xcal="urn:ietf:params:xml:ns:icalendar-2.0">

<xcal:properties>

<xcal:uid>

<xcal:text>14574d52-b9a7-449b-a1cc-312db74ceeaa</xcal:text>

</xcal:uid>

<xcal:dtstart>

<xcal:parameters>

<xcal:tzid>

<xcal:text>America/New_York</xcal:text>

</xcal:tzid>

</xcal:parameters>

<xcal:date-time>2011-01-02T09:00:00</xcal:date-time>

</xcal:dtstart>

<xcal:dtend>

<xcal:parameters>

<xcal:tzid>

<xcal:text>America/New_York</xcal:text>

</xcal:tzid>

</xcal:parameters>

<xcal:date-time>2011-03-31T00:00:00</xcal:date-time>

</xcal:dtend>

</xcal:properties>

<xcal:components>

<xcal:available xs:type="xcal:AvailableType">

<xcal:properties>

<xcal:dtstart>

<xcal:date-time>2011-01-02T09:00:00</xcal:date-time>

</xcal:dtstart>

<xcal:dtend>

<xcal:date-time>2011-03-01T11:00:00</xcal:date-time>

</xcal:dtend>

<xcal:rrule>

<xcal:recur>

<xcal:freq>WEEKLY</xcal:freq>

<xcal:byday>MO</xcal:byday>

<xcal:byday>TU</xcal:byday>

<xcal:byday>WE</xcal:byday>

<xcal:byday>TH</xcal:byday>

</xcal:recur>

</xcal:rrule>

</xcal:properties>

</xcal:available>

<xcal:available xs:type="xcal:AvailableType">

<xcal:properties>

<xcal:dtstart>

<xcal:date-time>2011-03-01T15:00:00</xcal:date-time>

</xcal:dtstart>

<xcal:dtend>

<xcal:date-time>2011-03-01T16:00:00</xcal:date-time>

</xcal:dtend>

<xcal:rrule>

<xcal:recur>

<xcal:freq>WEEKLY</xcal:freq>

<xcal:byday>FR</xcal:byday>

</xcal:recur>

</xcal:rrule>

</xcal:properties>

</xcal:available>

</xcal:components>

</xcal:vavailability>

In EMIX, the Business Schedule was merely a name, used to “hide” its origins. In EnergyInterop, it is modified to allow a collection of intervals to be expressed as well. There is no need to express a collection of intervals as well. Availability objects can be created with no recurrence to meet the same need. In the example below, the schedule for from now until year end includes several one-time intervals, shown in this case with a dtStart and a duration.

<xcal:vavailability xmlns:xs="http://www.w3.org/2001/XMLSchema-instance" xmlns:xcal="urn:ietf:params:xml:ns:icalendar-2.0">

<xcal:properties>

<xcal:uid>

<xcal:text>18b5a310-b83a-495e-be77-e2717c5f5a36</xcal:text>

</xcal:uid>

<xcal:dtstart>

<xcal:parameters>

<xcal:tzid>

<xcal:text>America/New_York</xcal:text>

</xcal:tzid>

</xcal:parameters>

<xcal:date-time>2011-05-28T00:00:00</xcal:date-time>

</xcal:dtstart>

<xcal:dtend>

<xcal:parameters>

<xcal:tzid>

<xcal:text>America/New_York</xcal:text>

</xcal:tzid>

</xcal:parameters>

<xcal:date-time>2011-12-31T00:00:00</xcal:date-time>

</xcal:dtend>

</xcal:properties>

<xcal:components>

<xcal:available xs:type="xcal:AvailableType">

<xcal:properties>

<xcal:dtstart>

<xcal:parameters>

<xcal:tzid>

<xcal:text>America/Montreal</xcal:text>

</xcal:tzid>

</xcal:parameters>

<xcal:date-time>2011-03-01T09:00:00</xcal:date-time>

</xcal:dtstart>

<xcal:duration>

<xcal:duration>PT2H</xcal:duration>

</xcal:duration>

</xcal:properties>

</xcal:available>

<xcal:available xs:type="xcal:AvailableType">

<xcal:properties>

<xcal:dtstart>

<xcal:parameters>

<xcal:tzid>

<xcal:text>America/Montreal</xcal:text>

</xcal:tzid>

</xcal:parameters>

<xcal:date-time>2011-03-02T14:00:00</xcal:date-time>

</xcal:dtstart>

<xcal:duration>

<xcal:duration>PT4H</xcal:duration>

</xcal:duration>

</xcal:properties>

</xcal:available>

<xcal:available xs:type="xcal:AvailableType">

<xcal:properties>

<xcal:dtstart>

<xcal:parameters>

<xcal:tzid>

<xcal:text>America/Montreal</xcal:text>

</xcal:tzid>

</xcal:parameters>

<xcal:date-time>2011-03-08T13:00:00</xcal:date-time>

</xcal:dtstart>

<xcal:duration>

<xcal:duration>PT5H</xcal:duration>

</xcal:duration>

</xcal:properties>

</xcal:available>

</xcal:components>

</xcal:vavailability>

If we did the same with a collection of intervals, we would see the following

<xcal:vcalendar xmlns:xs="http://www.w3.org/2001/XMLSchema-instance" xmlns:xcal="urn:ietf:params:xml:ns:icalendar-2.0">

<xcal:components>

<xcal:interval>

<xcal:properties>

<xcal:uid>

<xcal:text>d13d2db1-a33a-47b4-93e4-10038dc87f28</xcal:text>

</xcal:uid>

<xcal:duration>

<xcal:duration>PT2H</xcal:duration>

</xcal:duration>

<xcal:dtstart>

<xcal:parameters>

<xcal:tzid>

<xcal:text>America/Montreal</xcal:text>

</xcal:tzid>

</xcal:parameters>

<xcal:date-time>2011-03-01T09:00:00</xcal:date-time>

</xcal:dtstart>

</xcal:properties>

</xcal:interval>

<xcal:interval>

<xcal:properties>

<xcal:uid>

<xcal:text>6538df20-e827-4abd-84e6-3e8076611e49</xcal:text>

</xcal:uid>

<xcal:duration>

<xcal:duration>PT4H</xcal:duration>

</xcal:duration>

<xcal:dtstart>

<xcal:parameters>

<xcal:tzid>

<xcal:text>America/Montreal</xcal:text>

</xcal:tzid>

</xcal:parameters>

<xcal:date-time>2011-03-02T14:00:00</xcal:date-time>

</xcal:dtstart>

</xcal:properties>

</xcal:interval>

<xcal:interval>

<xcal:properties>

<xcal:uid>

<xcal:text>1ecb427d-e2c4-44ed-9822-bc1d2e99382a</xcal:text>

</xcal:uid>

<xcal:duration>

<xcal:duration>PT5H</xcal:duration>

</xcal:duration>

<xcal:dtstart>

<xcal:parameters>

<xcal:tzid>

<xcal:text>America/Montreal</xcal:text>

</xcal:tzid>

</xcal:parameters>

<xcal:date-time>2011-03-08T13:00:00</xcal:date-time>

</xcal:dtstart>

</xcal:properties>

</xcal:interval>

</xcal:components>

</xcal:vcalendar>

A further advantage of the vavailability over the array of intervals is that it may have a distinct begin and end date for the overall series. Such a being and end date could be tied to seasonal DR, to a Tariff, to an Opt In, to an Opt Out, etc.

In Energy Interop, we have introduced it into market contexts and business rules as well. We use this for notification windows, i.e., foo weekday DR availability, there may be merely a 20 minute notification window. For weeknight DR, you can use availability to require that notification come in between 3-5 in the afternoon. If you wanted, the same market could create Weekend DR requiring notification between noon and 2 on Friday.

There are many uses for this element, and we should, as asked by Rish, use it natively to avoid complicating the schemas.

“The single biggest problem in communication is the illusion that it has taken place.”
– George Bernard Shaw.

Toby Considine
TC9, Inc

TC Chair: oBIX & WS-Calendar

TC Editor: EMIX, EnergyInterop

U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee

Email: Toby.Considine@gmail.com
Phone: (919)619-2104

http://www.tcnine.com/
blog: www.NewDaedalus.com

emix message