May 2014
Column
AutomatedBuildings.com

[an error occurred while processing this directive]
(Click Message to Learn More)


15 Years and Odds and Ends

All I have is a scattershot article for a scattershot industry.

Toby ConsidineToby Considine
TC9 Inc

The New Daedalus

Contributing Editor
  


Articles
Interviews
Releases
New Products
Reviews
[an error occurred while processing this directive]
Editorial
Events
Sponsors
Site Search
Newsletters
[an error occurred while processing this directive]
Archives
Past Issues
Home
Editors
eDucation
[an error occurred while processing this directive]
Training
Links
Software
Subscribe
[an error occurred while processing this directive]

Fifteen years of Automated Buildings is an impressive accomplishment when even the Ladies Home Journal is ceasing publication. Bravo, Ken & Jane!

Such a moment deserves a momentous article, looking back at the tremendous progress that buildings have made, and the conversations that Ken has hosted. Unfortunately most buildings still use proprietary protocols, and immature security models. All I have is a scattershot article for a scattershot industry.

First on my mind this month is security. Security is not just locking everything down, it is making it easier for the right people to do the right thing at the right time. Without security, we can never open up buildings to reliable enterprise and personal interactions. Ken Masica’s article this month is a great overview.

The internet of Things, and yes, the Web of Things loom on the horizon. With these Things will come new protocols and new acronyms and new buzzwords. The building engineer will choose between capillary and cellular approaches, and doing so will stress some existing protocols. Capillary networks refer to the small pipes, but always connected, that we have used in buildings and sensors. On the other side is the occasionally connected cellular network. A point on a cellular network may change how it is connected, and may have less predictable bandwidth, etc.

Capillary and Cellular networks *may* use the same protocols. IP (as in TCP/IP) was created for unreliable, slow, not always connected networks at a time when there were no cellular networks as we would recognize them today. Vint Cerf built in assumptions that he could not know the path, that he could not guarantee order of delivery for messages, etc. into IP.

Message Queuing refers to a suite of approaches wherein tracking and delivery of messages is of more import than connectivity. MQ started out in big business server-to-server batch transactions in which the transactions might be inspected, logged, audited, before and after delivery between two entities. Often it was used as a sort of certified mail, with the sender receiving a receipt of guaranteed delivery including information to prove the message was delivered intact. Sometimes this is very important, and sometimes this is unnecessary overhead.

Building Systems have tended toward RESTful interactions when they use the web. Programmers who do not see the need for auditing and validation favor the simplicity of REST over the message passing of SOAP. But we have just climbed to another level of the networking stack….

A half dozen years ago, some of the guys in IBM who had worked extensively with MQ approaches began developing an extremely light-weight model for MQ, one that extended the queuing paradigm  down to very small devices, even to sensors. Sensor reading is often known as telemetry. They created the Message Queuing Telemetry Transport (MQTT).
MQTT is showing up as one of the preferred protocols of the Internet of Things, in part because it is well suited for cellular networks. The queuing means that the protocol is pre-adapted for intermittent or unreliable connections. Its parsimony makes it good for some very small devices. Development of MQTT is now managed by an OASIS Technical Committee (TC). That TC applied to the IETF earlier this year for MQTT to be classified as a sub-protocol of WebSocket. The OBIX TC spent considerable time developing a binding for WebSocket this year, meaning it is now ready for MQTT.

Choosing protocols is about to get more complicated again, all up and down the network stack.

The great uptake in data fed by telemetry on both capillary and cellular networks leads to terabytes of data. Big data chokes the traditional database server. When Korea began building out their big OpenADR integrations, they turned to Hadoop for their National Virtual Power Plant (NVPP) project. Hadoop is open source software that enables the distributed processing of large data sets across clusters of commodity servers. It is designed to scale up from a single server to thousands of machines.

This last month, Microsoft took steps to make Hadoop “safe” for the normal DBA. Microsoft announced its Analytics Platform System (APS) that links SQL Server 2014 to Hadoop. I expect to read soon in these pages of some vendor or consultant taming terabytes of “control spam” with the new tools.

[an error occurred while processing this directive]Along with big data comes the need for formal taxonomies. Haystack is a taxonomy to tame and classify the mounds of building telemetry. Last month I put COBie beside it. That assertion left too much to the imagination.

COBie is a Platform Independent Model (PIM) that links systems to space, space to zones, issues to systems, and spare parts to equipment. It lacks any taxonomy to make all of that meaningful.

For North America, the COBie specification recommends taxonomies from the Construction Specification Institute (CSI). In particular, OMNICLASS provides a hierarchical taxonomies for equipment and for spaces. Linking these two taxonomies together, using the abstract COBie information model, begins to move to one possible ontology of building activities. This ontology can provide the framework to understand the mass of telemetry that is coming, both from within BAS, and from external Internet of Things systems and sensornets.

Well that’s enough Odds and Ends for now. My guess is that these topics will appear increasingly in the next few years of Automated Buildings. Here’s to 15 years of issues, and to continuing reporting of the next big issue in the years to come.

footer

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

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

Events

Want Ads

Our Sponsors

Resources