Search Archives
Why New Daedalus?

Daedalus was the mythical great architect and artificer of the classical world. Today, embedded intelligence is enabling the most profound changes in the way we create and use buildings since his day.

Building Intelligence meets the Intelligent Building. The Intelligent Building negotiates with the Intelligent Grid. How will this transform how we interact with the physical world?

More on the Web
Login
Powered by Squarespace
« Big Data, Buildings, and the Internet of Things | Scheduling Resources and Operations with BIM »
Sunday
Mar112012

Easy integration of the Internet with Things: Calendar Subscription and  Syndication

I use Outlook in my day to day life. It shows me an aggregate calendar, with meetings I accept at the office (one account) meetings I accept not at the office (another email account) and two corporate calendars: one based in Exchange, and one in SharePoint. When I was working on the national smart grid roadmap, my Outlook showed the calendar of that SharePoint project as well. In Outlook, I can turn each calendar off or on, and when aggregated, each appointment was a different color by source. I live by Calendar aggregation.

In my Phone, which happens to be an Android, I used to have a calendar for each email account. Each has different security set-ups and realms. Each source has different policies about sharing calendar on distributed devices. It was easy to miss appointments when on the road as I switched between different companies.

With an overnight upgrade pushed out by my phone company, this changed to a single calendar. That single calendar is color coded, showing the source of each event. Some of the things that are on my phone are “not quite meetings”, when GMAIL has interpreted something as a meeting although I have not accepted the meeting. The rules GMAIL uses for this appear to be similar to, but not identical to, the workings of Google Calendar.

Because I speak regularly in front of large audiences, I am always working in concrete examples of abstract issues. I use my phone as a prop when talking about the problem of smart homes and vehicle charging. The narrative goes as follows:

  • This phone manages an ever changing set of security issues as dictated by my various calendar providers. Those security changes (passwords, policies, …) are things I do not want to build into my home. “I changed my password at work today—now I have to tell my refrigerator and my car” is not sustainable.
  • Whatever the security policies, the calendar that I can see on my phone is semi-public, i.e., it has already been de-securitized for sharing. It may be a top-secret meeting, but it is now in a state wherein I can look at it over dinner and say “No, not next Tuesday.” It is, in effect the external face of my personal (corporate) schedules
  • The phone is a “syndication point”; it syndicates each of the calendars that I subscribe to, to tell me what to do today.
  • The OLED screen on the magnetic computer stuck on the front of the refrigerator is another syndication point. It can subscribe to feeds from my android, the wife’s blackberry, and the kid’s iPhone, to develop the syndicated household calendar.
  • Note that each syndication point chooses what to share with downstream subscribers; the household calendar does not necessarily look like the sum of the upstream calendars. Policies about privacy and sharing, and key words that make a meeting “private” are managed upstream, and each syndicator can apply its own policies atop those.
  • There is no need for end-to-end security, no need for shared secrets the length of the chain.

I may choose to create additional information within the house. The party, family church, Sunday afternoon football viewing may all be events originating in a house-based schedule and not appearing in any of the subscribed calendars. Or perhaps the household calendar is just another subscribed calendar fed into the syndication. That is an implementation detail that no one but the magnet-on-the-refrigerator computer needs to know.

My phone Calendar, then is an aggregation of calendars that I potentially syndicate out to other calendars.

If we flesh out the needs of the electric car, negotiating expensive fast charges and cheap slow charges, it needs to negotiate only with this household schedule. It may learn its own secrets, such as how far I drive when I go to choir practice. It may learn off-the-schedule stuff, such as that I frequently stop at the bar (an extra 10 miles of driving range) on the way home from choir practice. It does not need to share that information upstream to my house, or with my electric utility. It merely uses this information itself to make decisions autonomously about charging strategies.

The car has its own calendar for sharing. Based upon what it has learned, not only about my schedule (from the house) but about my habits, it can create a schedule of charging needs. It syndicates *that* schedule to the house, and negotiates with the house for access to market. The house syndicates the requirements from all the systems it supports, and uses them to guide it market position in energy.

The same calendar may be syndicated in different ways. The house subscriptions may include multiple children of the same syndicate. The house may learn from its subscription to my Android that I am out this evening, and do not need heat and lights in my rooms. The house may learn from the Calendar in the car, that I need power before this evening to support that same trip out. It is OK for the syndication to affect the houses buying position twice. There is no need for round-tripping or end-to-end tracking. The information is consumed, decisions are made, and market positions are created.

OK, this is a nice tale of autonomous systems relying on aggregated schedule streams to create time-dependent market positions. It is time to start thinking about Calendar Subscription. Aggregation, and Syndication, and of touch-less integration with the Internet of things.

PrintView Printer Friendly Version

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>