Smart Energy uses schedule negotiation and schedule coordination to operate systems and equipment at the right time to take maximum advantage of variable energy supplies. As the internet of things grows up, it will move from gathering data from sensors to coordinating things to enhance our lives. The future of business breaks down into smaller entities with stronger missions that coordinate activities over time to support customers as if by a single business, only better. We all took steps closer to M2M (machine to machine) negotiation of these seemingly simple coordination results, at a meeting at AOL headquarters last month.

For the last decade, the Calendaring and Scheduling Consortium (CalConnect) has worked to improve the interoperation of tools that coordinate schedules. We use their standards to run our personal and business lives, every time we accept a meeting request by email. Their work is critical to smart buildings and smart grids. This week, they demonstrated how to extend this work to support live machine to machine (M2M) schedule negotiations, including schedule auctions. My mind is buzzing with the implications.

CalConnect, now a decade old, ebbs and flows as does any organization. CalConnect was founded in a flurry of activity to address, among other things, minimum capability cell phones, and worked through such problems as coordinating recurring meetings on a device too limited to compute once-a-week meetings. Today’s phones are more capable than personal computers then, and CalConnect has moved on to the problems of personal calendars in the age of social media. Calendar federation and social coordination bring new challenges.

Five years ago, CalConnect led the refresh of the aging standards for calendar information. iCalendar (RFC5545) is flexible and extensible, and describes key semantics and essential structure for everything you might see in your personal calendar. ITIP (RFC 5546) describes how to negotiate information between calendar-aware systems. You use it not only when you accept an email invitation, but also when that meeting is moved or cancelled.

Three years ago, CalConnect produced vAvailability, now moving to a standard in the IETF. (The Internet Engineering Task Force is the organization that manages the key specifications and communications of the internet.). VAvailability is used in smart energy to advertise changing schedules for energy supply and for demand response. EMIX (Energy Market Information Exchange) defines contracts for Energy Reserves as financial options linked to vAvailability. OASIS developed WS-Calendar in close coordination with CalConnect.

But that is in the past. This week was exciting for the demonstration of new work that expands the tools for schedule coordination. This week at CalConnect, multiple organizations demonstrated working interchanges of live schedule negotiations and schedule auctions. The essential interactions for resource advertising and exchange were front and center. Direct server-to-server communications of schedules without the usual email were demonstrated, along with specific hooks for authorized interactions between web sites and personal calendars, and between trusted business partners.

Distributed schedule-based auctions are at the core of smart energy, including the budding efforts for interoperable transactive energy agents.

ICalendar (RFC5545) defines a common grammar for creating information exchanges information related to schedules and defines  several such exchanges. The iCalendar event (vEvent) is familiar to anyone who has added a meeting to their calendar by clicking on a web site or opening an email. ICalendar defines other common exchanges such as tasks (vToDo) and alarms (vAlarm). OASIS WS-Calendar describes how to use iCalendar inside service oriented exchanges, with a focus on describing sets of schedule information that hang together in a series. There is a growing use of WS-Calendar world-wide in energy markets and smart grids.

vPoll is a new iCalendar exchange that uses iCalendar grammar to present a choice. Assume it is a simple meeting (vEvent). A vPoll could present a number of meeting times and ask the potential participants to vote. This is different than asking for a summary of when a recipient is currently scheduled (vFreeBusy). A recipient may choose to vote for a time knowing he can cancel a meeting. A recipient may be keeping that afternoon free for a visitor from out of town—even though nothing is scheduled. A recipient, for security reasons, may choose not to share any free-busy information.

vPoll further defines how responses go back to the originator. A poll typically includes an ending time for polling. The originator may choose to schedule the meeting in accord with the most votes, or when a few key personnel can make it or for any other reason. vPoll does not define the business rules or the application, just the messages and message pattern.

vPolls may be tied to prices rather than to votes. Maybe the single best price, or the three best prices, get invited to the meeting. Maybe prices determine the venue. The vPoll specification defines the BASIC Poll Type. Others will be defined later for specific use cases.

A recipient may choose to respond to a vPoll with vAvailability. Availability uses recurring patterns to indicate when something might happen, and what it might cost. Consider a meeting room in a commercial building. It can be scheduled during business hours, using the calendar, for free. After hours, because of additional security and custodial needs, the same room can be scheduled for $200 / hour with a minimum charge of $300. These schedules can be expressed with vAvailability.

So far, I have described vPoll using only meetings. A Poll can also include tasks (vToDo). A task is often distinguished by its required completion time. Recipients can use their calendars to bid on various completion times. Presumably, bid for completion tomorrow will be more costly than a bid for completion next month. VPoll can gather the bids and present them to the originator, to choose one.

In the world of Smart Buildings, vPoll allows buildings to add price (and energy) considerations to scheduling resources. Buildings that know their energy use, or the carbon footprint, to use a particular resource at a particular time, can put that information back into the decision process. For buildings, and for building systems, the question is how?

[an error occurred while processing this directive]Most of us think of calendar communications (ITIP) conveyed inside email (IMIP). We open email and we accept the iCalendar request. At the CalConnect meeting this year, multiple participants demonstrated interoperable iSchedule, used for direct server-to-server communications. This promotes the polling described above from the personal to the enterprise. This protocol is named iSchedule.

iSchedule defines the communications for direct Calendar Server to Calendar Server communications. This is a natural means for communication between the enterprise and a building. The BAS is not likely to have a mailbox, or to check it if it did. Using iSchedule, a remote server can check a BAS schedule. It can add new events to that schedule. It can negotiate prices.

This is a big step in enabling systems big and small to interact with our lives. The next step of business is improved provision of services across multiple businesses acting as a single personal concierge. But I will write more of that; later.

CalConnect invites interested organizations and companies to join CalConnect in moving the work forward. www.calconnect.org

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

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