When we look past the building, to the building’s interactions with the energy sources and markets outside the building, we move away from energy efficiency to energy resilience. Efficiency scenarios anticipate a ready supply of energy at a predictable cost. Site-based generation introduces intermittent energy supplies within the building. Smart grids anticipate swings between scarcity and abundance, with prices to match. Buildings must plan to support the businesses that occupy them, as they respond to these changing signals. Building integrators must be ready to embrace decreased efficiency to gain greater resiliency.

[an error occurred while processing this directive]

[an error occurred while processing this directive]

It is all going to come down to sharing rapidly changing schedules, changes or price and of availability, as a new revenue stream. Those schedules are going to be shared using the new OASIS standard, WS-Calendar.

iCalendar has long been the predominant message format for an Internet user to send meeting requests and tasks to other Internet users by email. The recipient can respond to the sender easily or counter propose another meeting date/time. iCalendar support is built into all major email systems and email clients. While SMTP is the predominant means to transport iCalendar messages, protocols including WebDAV and SyncML are used to transport collections of iCalendar information. No similar standard for service interactions has achieved similar widespread use.

The Calendar and Scheduling Consortium (CalConnect), working within the IETF, updated the iCalendar standard in the summer of 2009 to support extension (RFC 5545). In 2010, the same group defined XCAL, a canonical XML serialization for iCalendar, currently (08/21/2008) on the recommended standards track within the IETF. This specification supports extensions, including handling non-standard, i.e., non-iCalendar, data during message storage and retrieval.

WS-Calendar builds on this work, and consists of extensions to the vocabulary of iCalendar, along with standard services to extend calendaring and scheduling into service interactions. iCalendar consists of a number of fields that support the delivery, update, and synchronization of if calendar messages and a list of components. The components can specify defined relationships between each other.

Figure 1: iCalendar overview

WS-Calendar defines the Interval, a profile of the vtodo component requiring only a duration and an artifact to define service delivery and performance. WS-Calendar also defines the Association component, a container for holding only a service delivery and performance artifact, to associate with a component or group of components.

Figure 2: WS-Calendar and EMIX

A set of intervals that have defined temporal relationships is a Sequence. Temporal relationships express how the occurrence of one interval is related to another. For example, Interval B may begin 10 minutes after Interval A completes, or Interval D may start 5 minutes after Interval C starts. An Association linked to a Sequence defines service performance for all Intervals in the Sequence. Because each interval has its own service performance contract, specifications built on WS-Calendar can define rules for inheritance and over-rides with a sequence.

The Partition is a sub-class of a Sequence in which all Intervals follow consecutively with no lag time. Intervals in a Partition normally have the same Duration, but WS-Calendar does support overriding the duration on an individual basis.

A. Scheduling Sequences

A Sequence is a general pattern of behaviors and results that does not require a specific schedule. A publishing service may advertise a Sequence with no schedule, i.e., no specific time for performance. When the Sequence is invoked or contracted, a specific performance time is added. In the original iCalendar components, this would add the starting date and time (dtStart) to the component. In WS-Calendar, we add the starting date and time only to the first Interval of a Sequence; the performance times for all other Intervals in the Sequence are derived from that one start time.

B. Academic Scheduling example

Figure 3: Classroom Scheduling Example

[an error occurred while processing this directive] A college campus uses two schedules to schedule its buildings. In Schedule 1, classes start on the hour, and follow one after another; each class starts on the hour. In the second schedule, each class lasts an hour and a quarter, and there is a fifteen minute gap between classes; classes start on the half hour. On many campuses, the sequence in Schedule 1 may describe classes taught on Monday, Wednesday, and Friday. Schedule 2 may describe classes taught on Tuesday and Thursday.

The registrar’s office knows some key facts about each classroom, including whether it hosts a class during a particular period, and the number of students that will be in that class. The college wishes to optimize the provision of building services for each class. Such services may include adequate ventilation and comfortable temperatures to assure alert students. Other services may ensure that the classroom projection systems and A/V support services are warmed up in advance of a class, or powered off when a classroom is vacant.

Although most classes meet over typical schedule for the week (M-W-F or Tu-Th), some classes may not meet on Friday, or may have a tutorial section one day a week. The registrar’s system, ever mindful of student privacy, shares only minimal information with the building systems such as how many students will be supported.

The Registrar’s system schedule building systems using the Association (registrar’s information) and the student counts for each interval, and schedules the Sequence in classroom schedule 1 three days a week for the next 10 weeks. The Registrar’s system also schedules the sequence in classroom schedule 2 two days a week, also for 10 weeks.

This example demonstrates a system (A) that offers services using either of two sequences. Another business system (B) with minimal knowledge of how (A) works determines the performance requirements for (A). The business system (B) communicates these expectations are by scheduling the Sequences offered by (A).

C. Market Performance schedule

A factory relies on an energy-intensive process which is performs twice a year for eight weeks. The factory has some flexibility about scheduling the process; it can perform the work in either the early morning or the early evening; it avoids the afternoon when energy costs are highest. The factory works up a detailed profile of when it will need energy to support this process.

Figure 4: Daily Load Profile for Market Operations Example

Factory management has decided that they want to use only renewable energy products for this process. They approach two regional wind farms with the intent of making committed purchases of wind energy. The wind farms consider their proposals taking into account the seasonal weather forecasts they use to project their weather capacity, and considering the costs that may be required to buy additional wind energy on the spot market to make up any shortfalls.

Each energy supplier submits of the same sequence, a schedule, i.e. a daily starting time, and a price for the season’s production. After considering the bids, and other internal costs of each proposal, the factory opts to accept a contract for the purchase of a fixed load profile (Partition), using the evening wind generation from one of the suppliers. This contract specifies Schedules of load purchases (starting data and time for the sequence) for each day.

Building systems will have to plan for rapid reconfiguration to meet the new energy realities. Energy management systems will have to learn to use WS-Calendar.

[an error occurred while processing this directive]
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]