Digitizing Analog Sensor Data for the IoT

Unless you live in a cave without any media access (which, I suppose, would preclude your reading this blog) you have heard about the Internet of Things (IoT). According to the guardian, the term Internet of Things was coined by Kevin Ashton in 1999, a bit of anecdotal history that Cisco seems to confirm. A few hours of research and I was able to find a reference from Auto-ID labs using the term Internet of Things from 2001. Given that the Auto-ID Labs predecessor the Auto ID Center was formed in 1999 (see this), we can trace IoT back at least 14 years and maybe 16 years. Fifteen-ish years may qualify IoT as having one of the longest hype cycles ever, since it just reached the zenith of Gartner’s Hype Cycle last year.

So much for ancient history—the IoT is nearly passe, and now we are in the hype cycle of the Internet of Everything (IoE), and the Industrial Internet of Things (IIoT). I thought Cisco had coined IoE, but according to a date-windowed Google search, the domain has existed since as early as 2008 (note: running a Whois did not reveal the creation date), but the earliest reference I could find was an Economist article in 2010. The earliest Cisco reference I could find for IoE dates from 2012.

The Industrial Internet of Things seems to have been around for at least as long; I found an obscure International Sociological Association conference agenda from 2009 including a presentation Technology and Networked Memory: Toward an Internet of Old Things. The description for the presentation includes the term Industrial Internet of Things.

You are probably asking by now, where is this going? I've mentioned in other blogs that the IoT means basically every node is a sensor, and sensors are mainly inherently analog. This has led silicon vendors like ST Micro and TI to provide analog front ends and other building blocks to help get real, analog data into the digital domain. Unfortunately, that is only part of the problem—we still need to get the sensor data, even in digital form, to a monitoring system. That is where IIoT comes in, and in particular, wireless sensor networks and smart sensors in industrial settings. While it is great for consumers to control their lights or thermostats from their phones, Industrial sensor needs are in much higher numbers of nodes per installation, and require reliable but efficient communication methods.

Over the last few years I have been involved in some real-world IIoT application developments, and became aware of an interesting protocol that has gained a lot of use in the transport of digital data from sensor nodes to higher level application layers. MQTT is a protocol invented by Dr. Stanford-Clark of IBM, specifically for application to constrained devices and low-bandwidth, high-latency or unreliable networks . In laymen's language, the latter is a good description of a lot of the IoT. Oasis has many online resources including open source code for MQTT, and a nice overview presentation. Of interest are power consumption per “piece of information” of MQTT vs. HTTP. This article has data, which indicate MQTT has advantages in many applications, especially in short-range applications using WiFi instead of 3G.

While MQTT 3.1.1 is an Oasis Standard, a variant of MQTT, MQTT-SN has been developed by Dr. Stanford and colleagues at IBM specifically for sensor networks. For my purposes here, I don't need to dig into the differences, but MQTT-SN is worth looking at if you plan to be in the smart sensor business.

Brilliantly or ironically, depending on your point of view, MQTT is a “pub/sub” (publish/subscribe) protocol that works well with one to many and many to one architectures, without IP addressing. Also of importance is that MQTT is intended to support asynchronous data—consider a smart sensor that instead of sending temperature every minute, instead publishes temperature every hour and then only reports if the change is greater than some threshold. Such a scheme means you don't know when the next update may occur, but it lowers the power requirements quite a lot.

A common real-world implementation would be using an IEEE 802.15.4 wireless protocol to connect a whole factory of sensor nodes to a gateway. The nodes are identified by simple IDs, but more importantly they publish on various “topics”. Topics are defined by the implementation, such as “temperature” or “battery status”. The gateway would subscribe to those topics, and after registering the nodes, would simply “listen” for updates. Higher application layers would then handle what to do with the messages, which they would access via APIs (Application Programming Interfaces) to the gateway.

The gateway (which could be a virtual device running in a cloud) could be designed with APIs that are internet-accessible. Those APIs can be completely inside a corporate firewall, so no additional cyber-risk need be incurred, if that is important. Figure 1 is an example of combining REST (Representational State Transfer) APIs with an MQTT Broker, used with permission of the author Michael Koster of ARM. REST is relatively new to a lot of people and can be confusing, but you can get an introduction in this article from IBM.

Figure 1

The MQTT nodes publish updates that are routed by a broker; endpoints wishing to access information subscribe to Topics over the API.  In this example applications can also use a REST interface to the Broker.  Used with permission of Michael Koster, original is here.

The MQTT nodes publish updates that are routed by a broker; endpoints wishing to access information subscribe to Topics over the API. In this example applications can also use a REST interface to the Broker. Used with permission of Michael Koster, original is here.

Conceptually the architecture in Figure 1 allows, say, sensor node data to be used by multiple applications and multiple sessions. To put that most simply, there could be a web page that showed the temperature of all the nodes in a system. As many users as needed could browse to that page and view the data (with authentication if desired). A second application, say a desktop widget could alert when certain nodes exceeded a defined temperature range. There could be any number of users running that widget on their desktop simultaneously.

So where does this leave us? First, from the supplier point of view, I expect to see growth in smart sensor packages combining various types of sensors, AFEs, micro-controllers or microprocessors, a wireless chipset, and a protocol like MQTT in one package. From the user standpoint, once the network is in place, adding more nodes to it is as simple as activating a smart sensor and having it self-register to the broker (in the gateway). Approaches like these will drive higher use of sensors, corresponding to more demand for analog silicon for the signal conditioning and other aspects of the sensor hardware layer.

8 comments on “Digitizing Analog Sensor Data for the IoT

  1. Michael.Schelling
    April 15, 2015

    TSMC Launches Ultra-Low Power Technology Platform for IoT …

  2. eafpres
    April 15, 2015

    My apologies for mis-typing Kevin Ashton's name in the comments about crediting him with the first use of “Internet of Things”.  The correct spelling is Ashton, not Aston.

  3. eafpres
    April 15, 2015

    It is interesting to see the evolution of SoC solutions for M2M / IoT.  It has taken a long time.  Wavecom worked for 10 years developing chip solutions which combined an ARM core, memory, I/O, and cellular modems.  They were acquired by Sierra in 2009.  Siemens went down a similar road, they spun out their M2M module busienss as Cinterion in 2008, and Gemalto acquired the business in 2010.

    These developments and acquisitions, in my view, were based on the premise that you need a WWAN technology to meet remote sensing needs.  Certainly, for many applications that makes sense, but what I think we are seeing in the Industrial Internet of Things is an ecosystem approach, whereby low power nodes using short-range wireless technology are managed by a central location (gateway) and only the gateway needs to have WWAN access.  The numbers of these non-IP addressable nodes is staggering.  To me that is part of the irony of the Internet of Things–there will be huge numbers of nodes not directly connected to the internet.

  4. Victor Lorenzo
    April 15, 2015

    Nice post, Blaine.

    One more thing in favor of MQTT-SN , it has a low byte count payload, that means less power consumption for messages broadcasting.

    Its design also allows a relatively easy migration from one physical layer to another.

  5. eafpres
    April 15, 2015

    @Victor–thanks for the key point.  I know a lot of people would assume BLE or Zigbee would be just fine for IoT, but MQTT addresses real issues of what happens if the link is intermittent, power consumption, etc.

    If you have more direct experience with MQTT I'm sure readers here would like to hear more!

  6. Victor Lorenzo
    April 16, 2015

    Compared to MQTT, MQTT-SN reduces traffic over the underlaying communications link, e.g. in MQTT-SN topic id's are integer codes instead of char strings.

    IMO, MQTT-SN has the disadvantage of requiring nodes to keep state information, especially gateways and brokers. The connection establishment procedure is by itself relatively complicated and requires several trips. Good things are it is very easy to implement and debug with inmediate access to several open source libraries and receiving notifications or sending state information, once system is setup, can be very efficient in time and power consumption.

    MQTT-SN can be implemented over ZigBee, BTLE, Serial links, Sub-GHz, Ethernet (MQTT) and other physical layers, and implementing the physical layer is where we should expect the most complex part of the work, especially when dealing with half-duplex media like single wire and most RF transceivers.

    Up to some extent it could seem a little bit strange to run MQTT over ZigBee or BTLE, but not stranger to me than running it over ethernet networks.

    JenNet, from NXP, is another protocol focused on low power sensor networks, but it does define the radio link layer. It is based on IEEE802.15.4 PHY and MAC.


  7. sai praneeth
    April 17, 2015

    nice post

  8. anilvarm
    April 21, 2015

    great post

Leave a Reply