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.