Finding the right IoT development framework

January 13, 2014

Bernard Cole-January 13, 2014

In recent months, excitement has been building around a still somewhat ill-defined and overly general concept called the Internet of Things (IoT) in which every device with an embedded microcontroller would be Internet Protocol-enabled and potentially connectible to every other IP-enabled entity on the Internet.

But for many in embedded systems design world this excitement has engendered some puzzlement and frustration about a capability that they have been using since the early to mid-part of the last decade.

"In 1996, when we started, not many electronic devices were networked,” said Express Logic’s John Carbone, author of “Speed up machine-to-machine networking with UDP  “Over the years, that's changed and now most of our customers' products are networked.”

The introduction of IPv6 in about 1999 (and of 6LoWPAN about five years later) foretold the IoT, he said, as even then it was clear that the Internet would soon have to handle all sorts of intelligent devices.

"The IoT is not a new phenomenon, it's been growing steadily from the early days of the Internet, and will continue to evolve as new smart devices emerge,” Carbone said. “M2M has been replaced by IoT, but the idea is the same."

Typical of the recent enthusiasm for this new vision of ubiquitous IP-enabled connectivity were the companies gathered at last week’s 2014 Consumer Electronics Show with several conference tracks and panel sessions on the topic, and where numerous wearable electronics devices using IP-connectivity were on display.

However, the idea of IP-enabling every device, no matter what its performance requirements, is being met with some reservations and tire-kicking in many segments of the embedded market. Illustrative of this conservatism are industrial control and automation shows such as the AHR Heating Ventilation AC Refrigeration Trade Show later this month in New York. There, most of the conference papers and panels are focused primarily on the tried and true, well understood wired industrial networking protocols such as Lonworks and Bacnet, and where IP-connectivity, when used, is indirect through gateways that serve as intermediaries.

Some of the difference may be due to product lifetimes in the two segments – about a year in the case of consumer and mobile compared to about five years to several decades in the case of industrial control and building automation.

But a more significant factor is the different and conflicting requirements in consumer and industrial control, according to Echelon’s Robert Dolin, author of “Building an IoT for Industrial control,” a two part series included in this week’s Tech Focus newsletter.

“Unlike the industrial environment, consumer IoT is non-real-time and non-deterministic and characterized by a human interacting with a device,” he writes. “In case of failure, a human is there to recover or restart the application. In the consumer IoT, communications run between client/server and are often streaming large amounts of data. This is very different than Industrial IoT (IIoT), where, in terms of reliability and determinism, the requirements are a superset of the main IoT requirements.”

There is also some uncertainty about what is meant by “Internet of Things,” and how the ubiquitous IP-connectivity its adherents champion is different from what has been used by embedded developers since the introduction of IPv6 in about 2000 and the 6LoWPAN protocol wireless sensor suite added to it in 2007. Both have been deployed widely by embedded developers in a variety of wireless sensor, machine-to-machine, and wireless industrial control networks, as noted in this week’s Tech Focus Newsletter and in articles such as:

Plug in to M2M
IPv6 on a microcontroller
How to set up a 6LoWPAN network
UDP and the embedded wireless Internet of Things

The upside of the excitement about IoT, ill-defined as it still remains, may be that it is sufficiently “high-concept”  enough to grab the attention of company executives – and their IT departments – and give a boost to investments in more device connectivity and the tools with which to build them and monitor their activities.

But this is a mixed blessing because the focus of many of companies such as Cisco Systems, General Electric, Intel, Wind River, and ARM, among others, is to provide development frameworks that will appeal to IT developers more comfortable with developing Web application scripts or coding through an Application Programming Interface that removes them from the details of an MCU’s hardware interactions.

According to Wilfred Nilsen of Real Time Logic and author of “Get on the Internet of Things fast with an embedded Web app server,” many large companies and service providers, are pushing IoT as the next big thing since they see an opportunity to sell either large software packages or in providing IT services. Some of the alternatives coming from such sources that he deems as inappropriate for embedded real-time-oriented applications include:

* Ajax, Web services, RESTful communication protocols. These sit on top of HTTP, thus suffering from the same limitations as HTTP. Many of these protocols also require extensive processing and have a huge code size footprint. Many service providers promote the use of these protocols since their backend infrastructure is based on standard web servers that cannot handle any other type of protocol than HTTP.

* MQTT: A persistent publish/subscribe request/response protocol developed by IBM and supported by ARM. It can scale up to many nodes, but requires fairly complex code in the device. This protocol is not suitable for environments that include a proxy, as it is not designed to work via a proxy.

* AllJoyn: A persistent publish/subscribe solution promoted by Qualcomm. This protocol has the limitation of being mainly targeted towards home electronics. This protocol includes code for marshalling and unmarshalling (encode/decode) data and suffers from the same size and proxy problems as MQTT

* XMPP: An open source persistent publish/subscribe protocol that can also be tunneled over HTTP. Data is encoded in XML, thus it includes a huge code size footprint for the device

“Many, if not most, of these solutions are overly complex and more basic solutions would be more than sufficient for most use cases,”´ Nilsen said. “In most cases, the M2M device does not have to be particularly intelligent. For example, a pump connected via an M2M connection may have a simple on/off switch.”

Fortunately, a lot of work is being been done to come up with a new breed of IoT connectivity tools that will appeal to all segments of the market and developer community. Some recent journal articles and technical conference papers dealing with many of these issues include:

Middleware for an Internet of Things
Making sensor networks IPv6 ready
M2M: From mobile to embedded internet
Adding sense to the Internet of Things
Standardized protocol stack for the Internet of (important) Things

For those of you who want to get started making your embedded and connected designs IP-enabled, check out the technology and product news roundup of recent IoT, M2M, and wireless network technology tools and building blocks. Site Editor Bernard Cole is also editor of the twice-a-week newsletters as well as a partner in the TechRite Associates editorial services consultancy. He welcomes your feedback. Send an email to, or call 928-525-9087.

See more articles and columns like this one on Sign up for the newsletters. Copyright © 2013 UBM--All rights reserved.

Loading comments...

Parts Search