May 2014 |
[an error occurred while processing this directive] |
15 Years and Odds and Ends
All I have is a scattershot article for a scattershot industry. |
Toby Considine |
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 |
Overload. There are too many processes running under this userid. Please wait a minute and try again. (fork failed) |
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.
Overload. There are too many processes running under this userid. Please wait a minute and try again. (fork failed)
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]