AutomatedBuildings.com Column - Developing Shared Agendas for Enterprises, 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 to walk the dog, that you have to put out the cat, and that he has to take the kids to school. These messages use the semantics defined primarily in iCalendar (rfc 5545)

Much of Smart Energy requires scheduling of markets, at a certain time, or for a certain duration. The Smart Grid Interoperability Panel specifies using the OASIS specification WS-Calendar, which expresses iCalendar for use in services. The specification Energy Market Information Exchange (EMIX), used to exchange messages concerning the market value of energy over time, already incorporates WS-Calendar. The e-Commerce specification for smart energy, Energy Interoperation, also incorporates WS-Calendar. The code base for Bedework, an open source enterprise-class calendar server, includes services for updating and synchronization between calendar servers 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) is working on approaches that may change this using the internet standards vCard and LDAP.

The same PIM consortium that developed iCalendar, developed vCard. You probably know vCard as the format for business cards attached to email. The CalConnect has recently specified vCard v4, including a standard XML serialization. Schedules and meetings have long been associated with vCard on calendar servers.

CalConnect is working on a schema for representing resources for calendaring and scheduling using vCard and LDAP. In many companies, meeting organizers have long scheduled 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. Together, vCard and LDAP enable a standards-based 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; this interface could build on existing open source code. Resource vCards could represent rooms and systems. 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. They would be service oriented rather than process oriented; do not 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 open standards and open source code.

This approach 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 created through 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.

LDAP for Resources specification can make BIM more valuable by defining a means to submit LDAP queries to request specific BIM information. BIMs are large databases that can be difficult to navigate. A standard that defines how to generate vCard Resources as an interface to BIM, defines directory information for BIM. Applications using the resulting Resource vCards can take advantage all of the vCard and WS-Calendar functions. Together, 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 with which they will interact. WS-Calendar, vCard for Resources, and LDAP are part of this.

Events	Want Ads
Our Sponsors	Resources