Getting Over the Internet of Things

Ken Sinclair has been doing a great job stirring the pot on open systems and open standards, and open interfaces revolution in buildings and “things”. It is only as the buildings industry matures in how it uses these specifications that it will move past the unproductive arguments over the best protocol to something more useful. While we argue about the Iot, the WoT is coming.

The IoT is nearly 40 years old, now. I am arbitrarily taking the development of X10 in 1975 as its beginning. The IoT is a nest or proprietary things serving single applications or single vendors. The IoT is the family of single-scope products that the cable company and the home security company is using to expand their offerings. It is a dead end.

Throughout this year, I have been writing about some of the ways to get past the IoT. OBIX has always been about reaching to people and the enterprise. Therese Sullivan has introduced a new acronym (MQTT) to AutomatedBuildings this month that speaks of another route in her article IoT Opens to Mobile Messaging Standards the Direction is toward Open Standards. Enterprise computing, and personal computing, is all about combining protocols, using what William Cox calls the Architects Palette. The enterprise architect selects standards and blends them. This blending is a critical step on the road to the Web of Things.

Some writers and researchers are using the Web of Things (WoT) to name a semantically aligned IoT. The Web of Things moves beyond the parochial standards that we keep inventing in buildings (and elsewhere) and moves to higher level i.e., more abstract semantics. Like the Internet of Things, everything in the WoT has an URI (which is different than everything has an IP address…). In simplest illustration, in the Web of Things, there is no BACnet Light, no ZigBee IP Light, and no KNX light, not even an X10 light, there is only a light. That light is slowly being placed into a context using standard ontological methods, but that is taking two steps ahead.

This does not mean the end of the domain protocols. Far from it. Building protocols are the best for using internally to building applications. Buildings have seen over-extensions of domain protocols from the other side in recent years, as the smart grid folks tried to get buildings to abandon their domain specific languages to use those of the utilities. If you are inside a BACnet (for example) application, of course you should use the BACnet light. Just don’t expect anyone from outside your niche to adapt their language to yours.

OBIX has always been first and last about common low-level semantics. In the current drafts, wherein we broke out encodings and bindings, we were reaching to enterprise-style composition, to expanding the palette. MQTT is another expansion of the palette.

Most OBIX applications in North America uses REST interaction patterns. Some of the Asian and European implementations use the more message-oriented patterns of SOAP. MQTT is optimized for pure messaging with constrained devices. It is particularly suited for publish and subscribe in cellular networks. COAP, for which OBIX has recently defined a binding, is in a middle ground: some of the messaging and broadcast oriented aspects of IPV6 can also be used in cellular networks. If you want your sensor network to be readily adaptable to cellular networks, you will want to learn more about MQTT. (A discussion of the growing presence of femtocells it tempting, but does not fit here…)

There is no right binding for communications—there are only different problem constraints. There is no correct application protocol buildings, KNX, BACnet, LON, or SEP—there are only different application spaces.

When composition is considered, then a building system-oriented semantic model such as Haystack is placed in its correct place. Haystack creates mid-tier ontologies that, within their limited application space, buildings and energy, enable common applications across low level controls applications. That is immensely useful. That semantic model is less useful if it is tied only to a certain server, or a certain protocol. Haystack provides critical semantics with which to build an ontology for this specific domain. Haystack will be composed into the Web of Things when it aids in a particular application domain.

The Web of Things will not be built around specifications developed primarily within the buildings world. Building systems have only slowly embraced open specifications from the wider world, and often not very well. Old timers can remember when BAS systems could use IP, but only if specific routers were used. That finally stopped when BAS companies were told to fix the incompatibility or be banned from the enterprise network. As the WoT grows, the same will happen with semantic protocols. The semantic models from the BAS world will only be accepted in limited domains—even as they become more important within those domains.

The Web of Things requires secure, scalable directory services based on open standards. Directory services can be a source for these higher level ontologies. These services will not be developed within the BAS world. Just as MQTT now, and IP before, the winning directory services for the WoT will come from outside the world of things. I think it will be LDAP based.

Directory services common the enterprises and buildings will enable the composition of building-based applications and services into personal, enterprise, and trans-enterprise applications. As directory services are already the basis of personal and enterprise scheduling, so, too, will standards-based directory services connect building application scheduling to the wider business. This means that at least some of the semantics used in directory services for buildings will be based on enterprise standards such as LDAP and BIM.

LDAP exists within a rich ecosystem of security applications and specifications. Directory Services Markup Language (DSML) provides LDAP functionality for those who want pure XML. Many LDAP applications support declarative security directly. LDAP is well tested, widely deployed code that scales well.

BIM-based s directory attributes do not rule out other attributes. Haystack attributes, including the critical haystack relations between elements, can coexist easily within the same directory. In academic LDAP directories, employee-only attributes and student-only attributes coexist happily in the work-study student. Other semantic families, say for medical equipment, for manufacturing, or for security, will coexist with BIM and Haystack directory attributes.

For the AutomatedBuildings reader, this means that we should stop looking first to building new protocols. We should look first to expanding our palettes, to include more specifications from outside the world of BAS. An attitude of not-invented-here leads to the creation of applications that will not-be-sold there.

Events	Want Ads
Our Sponsors	Resources