This month’s theme is building bridges. A bridge spans two different areas that are perhaps quite different: different land, different culture, different cities. Bridges do not join two territories into one—that would be dredging and filling. We build bridges to connect two disparate things, not too make them one. Too often, through system integration, we try to make one large thing. This is expensive, and limits future choices. It slows the adoption of new technologies. The preferred approach is light, loose integration, perhaps even self-integration. Building bridges.

Discovery is essential to agile integration. If systems can discover each other, we do not need to map them. If systems can understand what they discover, they can integrate themselves. One of the requirements is service orientation, which hides process details to simplify interactions. I have often written about that. This month, I am writing about common semantics, about discovery, and about directory services for building systems.

In all creation myths, the first responsibility of the first man is the naming of things, i.e., defining semantics. A common semantic model is the foundation of bridges. It is not necessary for two systems to name everything that they do, just that they name aspects of the interactions. For energy interactions, OASIS EMIX names provides a high level abstraction of the semantics of energy services, both supply and consumption. Where more detailed information is desired the folksonomy Haystack provides common semantics for building automation systems. In time, systems are likely to be able to serve up Haystack semantics on request, and systems will be able to provide the appropriate bridges to service integration.

A mechanism for discovery is necessary before common semantics is of any use. Without discovery, all introductions between systems must be made by a human, probably an engineer, and we are back to models of detailed integration. Readers of Automated Buildings are familiar with many mechanisms of discovery, so I will write only of a new one, one that may be disruptive.

A new specification, entitled “Aggregated Service Discovery” is wending its way through the Internet Engineering Task Force (IETF). This specification specifies how a system can retrieve configuration for multiple services with a minimum of user-provided information, and as short as possible sequence of queries, and with a minimum of overhead for administrators of the services. From what I can determine, we will first see this specification when the Apple TV ships. It is based on top of common internet protocols. Its initial target is the home, and consumer electronics. It seems natural to assume that interactions with internet-aware thermostats such as the Nest or the Honeywell WiFi Smart will follow closely. Is this the beginning of Apps for Home Energy? It seems likely that this will find its way into commercial buildings shortly after introduction.

Personally, I have been thinking more about directory services for building based services. VCards have long been associated with calendars, although they have been much slower to be standardized than the core icalendar objects. The way to retrieve a vcard is with the universal security and directory model, the Lightweight Directory Access Protocol (LDAP). LDAP supports diversity of information returned, including security on particular aspects of the information. At universities, an LDAP will return different information when asked about a student or staff, even when the target is the same person. In LDAP, there is a long history returning different information about the same object in different security contexts. LDAP also supports multi-valued attributes easily. This is in sharp contrast with the normal expectations from, say, a SQL query.

Over time, a varied set of what I will call here, for brevity, vCard profiles has been developed. These often have object-type characteristics. For example, the inetOrgPerson (RFC2798) is defined as a standard set of extensions to the organizationalPerson as defined in the standard ITU standard X.521. Many colleges and universities have collaborated to define the eduPerson to handle students, grad students, and faculty. Just as in medical information, the portions of student information that can be exposed to query vary widely by querier and context, and are controlled by federal privacy law.

[an error occurred while processing this directive]Recently, attention has turned to resources, i.e., to those things that are not people. At the simplest level, resources are often subdivided into rooms, vehicles, and equipment. Completeness would suggest that business services be added to the list, as to encompass the Transportation and Catering services we have discussed in our calls. Many times there are multiple fungible assets exposed as a reset. For example, a motor pool might have a fleet of sedans. These areas have not been well standardized-although efforts are underway.

In office enterprise systems, there is a desire to query for the room that is nearby, that supports 12 attendees, and has a projector, and an internet connection. The UI providers (Outlook, et al.) are looking for standards they can build on. The natural source is the databases that support building design, maintenance, and operations. These information models are referred to as Building Information Models (BIM). I am participating in efforts to define the BIMCard, a standard resource vCard for room and equipment information derived from BIM. BIMCards can derive their semantics from those of COBie Lite, or of Haystack. The resulting attributes, when done, will be submitted as an RFC alongside the other LDAP profiles.

If you can find it, and if you can understand it, you can build a bridge. Enterprise services and building services will never understand each other in depth—nor should they. Building systems in different silos may never understand each other. With simple services, they can interact without direct integration. With discovery and directory services, they can find each other to interact.

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

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