Last week, I posted an introduction to this blog series, called What Marketing Won’t Tell You About the Internet of Thing And What We Can Do About It. Despite my link-bait title, I quite like the Internet of Things and all of the wonderful connected devices. However, I’m wary of depending on my engineering skills to set up what are supposedly consumer devices.
In this installment, I’m going to provide a framework for how devices get connected and give some examples showing specific methodologies. In the future, we’ll build upon this framework with the goal of understanding the IoT options and tradeoffs available to designers and engineers.
While the canonical seven-layer OSI model of communication is a work of profundity, communication is not the only important factor in building an Internet of Things device. Breaking the system apart according to the device, communication, internet connection medium, cloud, and user communication allows me to look at the technical options while still viewing the entire connected system.
The device box represents, well, the device. Many soon-to-be IoT devices were perfectly usable before connection: pedometers, bathroom scales, cars, etc. It is straightforward to consider how this device works on its own. We often have more trouble imagining the possibilities of having the device connected.
On the other hand, there are devices that make no sense without connectivity. Consider those acoustic sensors detecting gunshots; one sensor is uninteresting, it requires the aggregation of data to form something interesting.
The communication box represents how the device talks to the internet: WiFi, cell modem, Bluetooth, etc. Note that it also touches the device so we have to take into account how the device talks to the communication method: a serial or parallel interface? At what speed? With a standard interface?
I initially added the Internet explosion box to remind myself that Bluetooth modules don’t communication directly to what we usually term the Internet. Instead, they talk to a dongle on your computer or to module in your smart phone. Bluetooth devices need to have a translation layer to get from your device to your server.
The cloud represents the server where your data lives. It may aggregate different devices with different communication methods. It may be owned by your company or you may use one of the cloud services available.
Finally, we need to consider the interface to the user. If data is sent to the cloud, there should be a way to display it, often differently from any display on the device. For example, while the bathroom scale may display the bad news to me daily, it takes the aggregation from the cloud to display a chart over time.
With that model in mind, let’s consider a few examples of connected devices.
The original Kindle was a book-reading eInk device. The communications were done via a CDMA cell modem (which is just cheating… except for the cost). With a keyboard and a display on the device, configuring it was relatively simple.
As for the Internet box, we often pretend that cell modems go directly to our servers but they actually go through a cell provider with all the overhead and hassle that implies. There is a manufacturing step where the cell modem’s phone number is connected to a destination IP address. Don’t forget that step.
The cloud for the Kindle was Amazon (and Amazon.com, not Amazon’s cloud services). The user has access to their electronic bookshelf from the website or from their device.
Moving on, let’s consider a WiFi enabled scale. The device is well understood, we’ve been using scales for a long time. Bathroom scales existed before electronics. And electronic bathroom scales existed before the Internet of Things.
For communications, scales can use an off-the-shelf WiFi module. The module required the device run a TCP/IP stack which, in turn, pushed the device to run an RTOS. Thus, the communication box modified the device to change it, adding requirements to support communications.
The internet here is straightforward; the WiFi module connected to the user’s home network. For configuration, Javascript webpages were served up from device to the user’s browser or to a PC setup program. Sadly, there was lots of confusion due to changing WiFi access points during configuration.
Once connected, the system could use HTML URLs to send data to the site servers. There, information is stored in databases and presented to the user via pretty webpages and smart phone applications. The initial datum from the device is shown on the device (e.g,. the bad news for the day) but long term trends are from other interfaces.
Finally, I want to consider the example of a BTLE pedometer. Like the scale, the device is easy to identify, we've had pedometers for a while, counting our steps without connecting to anything else. Along comes Bluetooth and then the Low Energy version (4.0). The off-the-shelf BTLE module we used required a stack on the device’s processor. It required fewer cycles, less RAM, and less code space than a TCP/IP stack but still this BTLE module was greedier for device resources than a simple serial peripheral.
As mentioned in the last post, Bluetooth (and BTLE) devices cannot attach to the internet directly; they require an intermediate bridge: a smart phone or a computer. Smart phone users have it easy though system developers have to write an app to talk to the device. Computer users may need a dongle (as well as some software). These communication bridges need to be on for the IoT BTLE device to connect to the internet.
The phone or computer app can then communicate the data to a server though its normal WiFi channels (so probably HTML URLs). The communication latency can create interesting difficulties, for example, if the device can connect to a smart phone to update data but the smart phone is not within range of a cell network so it cannot transmit the data to the server. (Alternatively, when the server can talk to the app but the phone or computer cannot talk to the device.) This asymmetry in communication can lead to data discrepancy problems that are as difficult to fix as they are difficult to reproduce. Additionally, the layers of communication (cell modem, cell tower, cell phone ISP, internet) lead to delays: network latency means that cell modem IoT devices may not be as responsive as WiFi IoT devices.
How would you fit your system into this framework? Do you already have a system in mind? Do you know how you are connecting it? If so, then the next posts are going to warn you about the common pitfalls so you can try to avoid them.
If you don’t have everything settled, my goal is to help you identify the tradeoffs to make a better system.
You will need to know the bottlenecks: your required data speed in both directions, the anticipated amount of data needed, the working distance requirements. You’ll need to know a lot of things, actually. I have lists of questions for you later.
However, don’t expect a magic solution. No matter which communications options I’ve chosen in past product development, I have always wished (at some point in the project) that I could have changed it.
Some example communications modules:
- Gainspan’s WiFi module with I2C, SPI or UART device connections
- Enfora’s GSM/GPRS cell modem
- Panasonic’s BTLE (4.0) module
