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 comprised of AT&T, Cisco, GE, IBM, Intel among others 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 this month. That’s one sign that DDS is going to gain even more notice and consideration among the Building Automation app development community.
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 subject 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.