原创 Understanding pub/sub, the Internet of Things, and 6LoWPAN connectivity (Part 2)

[Continued from Understanding pub/sub, the Internet of Things, and 6LoWPAN connectivity (Part 1)]

Connext 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.