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
« Podcasting Open Source Smart Energy | Planning for Abundance »
Monday
Nov282011

Sharing Agendas with Buildings and Other Things

Schedules for things have always been different from schedules for people. With things, schedules are step-by-step. Turn this switch on at 2:47. Start cooling at 3:00. We schedule people by results. Be at this meeting at 9:00. Complete the annual reviews by December 20. We expect people to schedule time to get dressed, walk the dog, drive to work, get some coffee, and be in the conference room at 9:00. In IT, we call this a Service orientation, as we request the service (be there on time) rather than the process.

The schedules of our lives have a service orientation. People all over the world may receive the same notice of the same teleconference. One click and it is on our calendar. That click is the same; the message is the same no matter what software we use. That message does not acknowledge that I have a dog, that you have a cat, and that he has to take the kids to school. These messages use the semantics described primarily in iCalendar (rfc 5545)

Because so much of Smart Energy requires scheduling markets, for a time, or for a duration, the Smart Grid Interoperability Panel specifies using the OASIS specification WS-Calendar, which expresses iCalendar for use in services. WS-Calendar has already been incorporated in the specifications Energy Market Information Exchange (EMIX) that is used to exchange messages concerning the market value of energy over time. WS-Calendar is also used in the e-Commerce specification for smart energy, Energy Interoperation. The code base for Bedework, an open source enterprise-class calendar server, includes services for updating and synchronization using WS-Calendar. WS-Calendar hasn’t yet gotten to buildings.

Buildings are filled with systems that use different technologies and barely communicate with each other. Some building automation systems expose nothing more abstract than a list of tags and values. Others are linked to full three-dimensional Building Information Models (BIMs) with included energy models. None of them exposes a consistent interface for service interactions.

The Calendaring and Scheduling Consortium (CalConnect) working on approaches that may change this using the internet standards vCard and LDAP. VCard was developed inside the same PIM consortium that developed iCalendar. You probably know it as the format for business cards attached to email. The Consortium has recently specified vCard v4, including a standard XML serialization. Schedules and meetings have long been associated with vCard on calendar servers.

The Consortium is working on a schema for representing resources for calendaring and scheduling using vCard and LDAP. Many are used to scheduling resources when, for example, a conference room is invited to a meeting. The Lightweight Directory Access Protocol (LDAP) is in common use not only for internet directories, but also as an integral part of many security systems. These standards together enable a standard way to search for and schedule resources within a calendar server.

This opens up a number of interesting possibilities. A building automation system could expose a calendar server interface based on open source code. Rooms and systems could be represented by Resource vCards. Enterprise servers and simple clients could search for these Resources using LDAP, and schedule them using WS-Calendar. These schedules would be semantically different then control system schedules as they would be service oriented rather than process oriented; don’t begin cooling the room at 9:00, have the room cooled by 9:00. Building systems and enterprise calendar systems like Exchange could synchronize resource schedules, again, using existing open source code.

This hides a lot of complexity while supporting considerable diversity. VCard supports simple hierarchies, so all rooms in a given zone can be linked. For a simple upgrade / retro-commission, the commissioning agent could simply create resource records and integrate them with the underlying systems and tags. For a modern building with a BIM in place, the resources and relationships could be generated automatically. Plans are underway to specify how to backlink such Resource vCards back into the BIM. Whatever the underlying technology, the BAS would present a common simple scheduling interface.

I am particularly intrigued by the possibilities tied to the standard use of LDAP for resources. Secure searches for a Resource across multiple BAS-Calendar Servers could become the norm. The matching Resources could share free-busy information, or availability information, or even the new VPOLL information.

BIMs are large databases and can be difficult to navigate. A standard that defines how to generate vCard Resources as an interface to BIM can take advantage all of the vCard and WS-Calendar functions. The LDAP for Resources specification can make BIM more valuable by providing a means to submit LDAP queries for specific BIM information. VCard and LDAP can become a standard means to access portions of a larger BIM.

Standard calendar interfaces to building systems and services can build on existing notions of calendar security. In an enterprise calendar, you may be able to see full details on another’s calendar, or only if they are free. You may be authorized to accept meetings for another’s calendar or see nothing at all. As calendar servers and mail servers are often linked, an administrative assistant may receive all invitations sent to someone he supports. These well understood and well developed security specific interactions would be available to BAS servers in this model.

Increasingly, the internet of things will integrate with the internet of people. This will only be successful when we make things look like people to the systems and users they will interact with. WS-Calendar, vCard for Resources, and LDAP are part of this.

PrintView Printer Friendly Version

Reader Comments (1)

I think this is an excellent synthesis. Almost all building reservations and expectations are built around a particular time of event. The calendaring metaphor feels just right.

I like the distinction between start heating at 8:45 and have the room warmed by 9:00. You call this 'service' v 'process' oriented. In performance, this is the stress to BE there at 9:00, not start getting ready at 9:00.

It's also like factory scheduling, where each Part has a lead-time to buy and each Assembly a lead-time-to-make. In that kind of a framework, the service request to have the room heated by 9:00 is a State that has a lead-time-to-establish. Similarly, the service request can be processed one layer down and reveal the implied process schedule. I think you have to have/be both models at once, because different clients might hope to access the two differing perspectives. Customers reserve a room, the process is then whatever must be arranged.

In an ITSM service model, the customer gets services, and doesn't/shouldn't have to attend the lead time and preparations -- those are for the service provider to think about. Of course on the service provider's calendar, every preparatory step must appear. So really, these may be two sides of a coin.

A nice plus is that facilities can be scheduled in the very same interface as all the other event scheduling for an organization. This is cool, Toby.

December 20, 2011 | Unregistered CommenterThomas Considine

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>