June 2014 |
[an error occurred while processing this directive] |
IIoT Middleware Choices
DDS middleware poised to gain traction for the Industrial Internet of Things
|
Therese Sullivan, Principal, www.buildingcontext.me 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] |
Now that most modern buildings are equipped with IP-based networks utilizing Ethernet, IEEE 802.11 and other popular wired and wireless protocols, achieving network connectivity among diverse building system components – digital thermostats, lights, cameras and other security ID technologies – is not today's challenge. However, connectivity is not interoperable data sharing. A defining feature of the coming Internet of Things (IoT) is standardized open data sharing among connected devices – and that is still a future hope for device makers and App developers.
A new Industrial Internet Consortium AT&T, Cisco, GE, IBM, Intel was announced in late March with the goal of achieving consensus on standards for the industrial Internet. As Barry Haaser, Executive Director, LonMark International, explained in his automatedbuildings.com interview in December, The Industrial IoT refers to "industrial objects and non-consumer applications, such as building automation, lighting control, restaurant equipment, etc. IIoT solutions must meet the challenging requirements involving industrial-strength reliability, hardened security, wired and wireless connectivity, and backwards compatibility with large installations of legacy devices." This year, the LonMark organization is migrating its interoperability platform to support the Industrial Internet of Things (IIoT). It has already added support for IPv4/6-based chipsets and it is committed to emerging IIoT communication technologies.
In previous posts, I waded into the subject of those communications technologies, specifically mobile messaging for the Internet of Things and publisher/subscriber communications. I thought I could keep my head above the deep waters of software architecting. But, as usual, I learned that I have a lot to learn. One of my readers, James Butcher, Applications Engineer at PrismTech, commented:
“Yes, I agree that the pub/sub style of communication is best suited for the dynamic and flexible nature of the Internet of Things. MQTT is one such protocol that is appropriate and very successful in this domain but there are others too. The Data Distribution Service (DDS), for example, is able to share data in a pub/sub manner but using a peer-to-peer distribution model and numerous Qualities of Service (QoS) to tune the data delivery requirements. I think the main differentiator of DDS is that it sends "Data" as opposed to messages. It does that by defining a global concept of what data is to be distributed. DDS has both commercial and open source implementations and is gaining a lot of traction in the industry. I think its likely that as IoT systems become more sophisticated these protocols and technologies will have to co-exist so its important that bridging software and the ability to connect sub-systems together exists.“
James
offered this comment just a few days after the announcement about the
IIoT Consortium. Being almost as good at scanning for key phrases as a
Google spider (not) I caught that the new consortium is under the
management of the Object Management Group (OMG) and that the evolution
of the DDS protocol that James describes has also been under OMG
supervision. Also, James’ employer PrismTech is another member of the
consortium. Angelo Corsaro, Prism Tech CTO, offers this distinction
between DDS and MQTT in a 2013 Article: "MQTT is most suitable for
sporadic messages and highly resource constrained devices whilst DDS is
most suitable for those applications that require real-time data
exchange."
The
different use-cases for DDS versus MQTT were a topic at the 2014 IoT
Dev-Con held May 7-8, 2014 in Santa Clara, Calif. The CEO of another
IIoT Consortium member, Stan Schneider of RTI, presented on the topic
of IIoT Protocols to an audience of software and system developers
attempting to tackle the challenges of IoT implementations. His advice
was to use DDS for real-time control and MQTT for data collection.
Two of the primary IIoT consortium members - Cisco and Intel - along with other IT majors - Google and Microsoft - plus the Building Automation industry’s own open protocol leader - Tridium - will all be on the podium to discuss the IoT's impact on commercial and corporate real estate at IB-Con next month. That’s one sign that DDS is going to gain even more notice and consideration among the Building Automation app development community.
[an error occurred while processing this directive]Admittedly, my technical depth was exceeded by James’ explanation that “the main differentiator of DDS is that it sends data as opposed to messages.” So, here’s a tutorial article on that by RTI's Stan Schneider entitled ‘What’s the Difference Between Message-centric and Data-centric middleware?’ This article offers some definitions and guidelines about the different approaches, system capabilities, strengths, and weaknesses.
The other important takeaway point from James’ comment is that “like the MQTT messaging standard, DDS has both commercial and open source implementations.” For this reason, DDS is a strong foundational technology for building Building Automation and Control Apps.
[an error occurred while processing this directive]
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]