The pace of development of next-generation “Internet of Things” (IoT) networks of wirelessly distributed sensors is speeding up, driven by a first wave of IoT devices from companies such as TI, STMicro, and Digi International. Embedded developers are starting to explore commercial IoTs based on the current TCP/IP standard , and using paradigms such as the lightweight MQTT protocol for delivery over current Wi-Fi and Zigbee wireless sensor networks.
In addition, researchers are already working on hundreds of projects using the next-generation IPv6-based 6LoWPAN protocols in a variety of wired and wireless environments. Many of those projects, especially within military and government organizations, such as the Department of Defense, Department of Homeland Security, and Department of the Interior, are now deploying networks of many thousands of sensors in a variety of monitoring applications .
But before commercially viable projects can be developed using this technology, there are many questions that remain to be answered, including:
* How do you manage thousands of remote devices occupying URLs in IPv6-based 6LoWPAN networks?
* How do you collect information from such devices and then distribute it to the correct locations?
* How do you allow decision makers to quickly communicate about the use of this information?
* Once a decision is made about the status and deployment of information collected, how do you send that information back to the appropriate locations, even to the remote sensors themselves, and how do you do so in a manner that is compatible with the real-time, deterministic nature of such communications?
To deal with these and other questions, many developers are making use of communications links based on a number of ad hoc and just barely standardized variations of the common publish-subscribe paradigm, combining them with a User Datagram Protocol subset of the full TCP/IP suite to achieve some degree of real-time and deterministic operation.
A typical publish-subscribe system is organized around the concept of publishers and subscribers. A system or device broadcasts (publishes) “topic issues” over a network to receiving devices (subscribers) that have registered an interest in that topic.
Pub/sub middleware manages such broadcasts so that the subscribing remote sensor applications simply respond to the messages that are appropriate. In that sense, pub/sub is similar to the common message queue paradigms such as Java Message Service (JMS) and RSS feeds.
DARPA and the DDS
But for most real-time and deterministic embedded IoT applications involving controllers, networked sensors, robotics, and remote control, the current pub/sub mechanisms are at best ad hoc and at worst inadequate.
Researchers are developing work-arounds using a number of related 6LoWPAN sub-protocols and mechanisms, but for sophisticated solutions, the best place to look is within projects funded by the U.S. Department of Defense and its Advanced Research Projects Agency (DARPA).
Much DARPA's work on pub/sub has been centered around frameworks based on the Object Management Group’s Data Distribution Service (DDS). In fact, for the U.S. military establishment almost anything about the real-time, deterministic use of pub/sub and DDS is a case of “been there, done that.” Examples of such projects include the Tactical Internet, the Global Information Grid (GIG), and the Sensor Cloud Project.
GIG is a communications project defined as a globally interconnected, end-to-end set of information capabilities for collecting, processing, storing, disseminating, and managing information on demand to soldiers, manned and unmanned units in the field, manned and unmanned aircraft, policy makers, and support personnel. In GIG, “situationally aware” networks of sensors will play a major role. The aim of DARPA's Tactical Internet is the creation of a command and control capability down to the smallest device and system, supported by a horizontally and vertically integrated digital information network.
The work being done under DARPA sponsorship on proposed net-centric “sensor clouds” of diverse wired or wireless sensor networks is particularly intriguing. These networks are integrated into a cloud computing infrastructure that allows real-time sensor data collection and the sharing of computational and storage resources for sensor data processing and management.
Real-time embedded system developers who have worked with interfacing or bridging to the Global Information Grid (GIG) have been faced with the challenge of maintaining deterministic behavior while moving large quantities of information over non-deterministic network transports.
For the military, when combined with sophisticated database management systems, DDS represents a middleware solution that has a number of advantages, chief among them simplified network programming. Nodes that produce information (publishers) create “topics” (e.g., temperature, location, pressure) and publish “samples.” DDS takes care of delivering the samples to all subscribers that declare an interest in that topic. DDS handles all the transfer chores.
But for many of the new Internet of Things applications distributed across thousands and even millions of sensors, this approach has limitations relating to scalability: from large computer systems to limited resource MCUs, from low speed home and wireless networks to high speed backbone networks, from embedded MCU device developers who work in environments that are real-time and resource constrained to IT personnel familiar with implementing large server-based corporate DDS systems across heterogeneous networks.
C onnext DDS to the rescue?
Real Time Innovations announcement that it would soon make available its new Connext DDS real time publish-subscribe communications framework is what got me thinking about the implications of the IPv6-based 6LoWPAN Internet of Things and what it will take for embedded developers to integrate the new protocols into their connected designs.
RTI may have a pub/sub implementation that will meet many of the diverse requirements of the still emerging commercial embedded Internet of Things, although most details of its new Connext DDS are still under wraps. RTI has built its new Connext DDS framework around three essential elements:
1. The DDS Integrator used to link independently developed DDS and non-DDS applications and which acts as a middleware to transform data types to provide interoperability between independently developed DDS apps;
2. Connext Messaging, which includes a variety of enhanced messaging capabilities, including Java Message Service (JMS) and distributed logging APIs, real-time data recording and playback, and run-time services for federation and persistence, an important consideration in many wirelessly connected 6LoWPAN-based IoT apps.
3. A small-footprint messaging capability for use on resource-limited devices using a subset of its DDS API and its DDS-RTPS (real-Time P/S) wire protocol. This will make the scheme scalable across the diverse range of 6LoWPAN-based IoT apps.
The RTPS subset built to operate in constrained sensor and controller environments should make it possible for developers to build apps that are independent of the underlying transport and protocol.
Unlike some 6LoWPAN IoT implementations, TCP and IP are not required. I suspect its use of a reliability protocol that supports Disconnected, Intermittent, and Low-bandwidth (DIL) operation, all too common in wireless sensor networks, makes it more attractive in 6LoWPAN implementations. Data is sent in a compact binary representation, and most metadata is only exchanged once, at discovery time.
But the linchpin that makes it all hang together is an updated and much improved version of a dynamically modifiable framework that incorporates elements of DDS and a Relational Database Management System. This allows data distributed by the DDS to be automatically stored in a relational database management system and accessed via SQL or ODBC interfaces, and, conversely, allows the contents of a RDBMS to be automatically distributed via DDS.
Rules are specified for translating between a DBMS table record and the DDS wire format representation. It provides mechanisms for preventing publication of data seen by DDS, and for preventing application of changes already made in a DBMS table.
By allowing relational database table updates to be propagated in real time to the embedded nodes, each small footprint Connext device can make use of the DDS API to subscribe to a DDS topic associated with a data table.
When the table is altered, either by an enterprise application (via SQL) or an application as small as that on an MCU-based sensor using the DDS API, the local table is updated and the update information is published via DDS for consumption by all interested DDS subscribers. This allows information to be seamlessly bridged from an enterprise application to an embedded real-time application.
What I have learned so far about the new Connext DDS tool suite makes me think it will be a valuable tool in the development of next-generation sensor net designs. But until more information is available, I have these questions:
* Is Connext tied only to pub/sub configurations of its own design, or is it flexible enough to be useable with other variations?
* What is the lower range of MCU capability on which it can be used, and is its use dependent upon particular architectural features?
* The documents I have seen so far only indicate that neither TCP or IP are required for operation. Is that because Connext is based on the UDP subset and can’t operate with the use of TCP/IP? Or can either TCP or IP be used as options?
* Some of the 6LoWPAN applications operate with amazingly small amounts of resident memory. How memory-intensive are low-end MCU-based implementations of the Connext DDS?
A lot of these questions are likely to be resolved when the company formally rolls out Connext DDS. But, what has emerged so far is tantalizing in what it implies about the range of applications in which it can be used. As commercial opportunities arise outside of current mil/aero and factory system controller management applications, it certainly looks like RTI will have a head-start in a variety of pub/sub based IoT designs.