Not long ago we covered the launch of Ayla Networks, whose goal is to simplify creating the Internet of Things (IoT). It sounded straightforward enough at the time.

That article spawned some further discussions that brought to light both the fact that there are a bunch of companies doing bits and pieces of this already and the fact that this isn’t as simple as you might think. And frankly, it’s really quite difficult to figure out what some of these companies are doing. They all sound more or less the same at the top level (“We help you to build the Internet of Things”), but they’re not. They can be stingy with information – some of the websites seem practically hipster with their vague promises and almost no detail (“It’s really obscure technology; you probably wouldn’t understand it”). (I also found the one with the least detail was also the one that didn’t respond to my questions…)

So I wanted to come back to the topic and add some levels of nuance to the deceptively rosy view that might have been derived from the Ayla piece. My goals are two: try to generalize an architecture for the IoT and then look through some example companies and show what they do within that structure.

To be clear: this will not be definitive nor will it be exhaustive. There is no defining architecture at this point, so the best I can try to do is simplify and generalize what I see going on. And I don’t think there’s any way I could be exhaustive; there’s a lot going on, and I would expect it to change constantly. So even if I could find an end to a search for more companies I had never heard of, that tail end would soon be obsolete.

So my goal is to give a more detailed flavor of the pieces of the IoT and how they’re being provided in order to help you to understand the various options and approaches out there. Before they’re out of date. To be clear, there’s lots more detail under this level. I won’t be going there. This time, anyway.

An IoT Architecture

As I noted in my earlier piece, there are lots of little things that have to be managed to get Things to talk to the Cloud and thence to other Things or Phones or Computers. So, in an effort to generalize the picture, I have broken everything down into five elements (and, conceivably, you could say four): Things, Hubs, the Cloud, Phones, and Computers (Phones and Computers could realistically be combined as Terminals, but I’ll leave them separate). They’re shown in the figure below.

The players in this scene are the folks making Things, whom I unmysteriously refer to as ThingMakers, Cloud Providers – guys like Amazon, and IoT merchants/vendors – the folks that are selling pieces of infrastructure to help in the IoT build-out.

First comes the Thing. Obviously, this covers a huge range of possible devices with different levels of complexity and power. One could be extremely small, with minimal computing and less memory; another could rock a sizeable processor and be able to host an embedded relational database.

• At the bottom of the stack is the hardware itself, most of which is under the complete control of the ThingMaker. The specific communication and computing aspects may be add-ons, or they may be IP that the ThingMaker can incorporate into their design, meaning less that they have to figure out how to do.
• Next up are the OS and basic communications stack. Depending on the size of the Thing, it may or may not have a full-up OS. But for this to work, it’s got to have a comms stack – either native (e.g., with the OS), custom, or provided by an IoT merchant.
• While communication is central to the IoT, most ThingMakers aren’t going to want to work down at the basic stack level; they’re going to want to abstract that communication using a set of higher-level APIs – things like “connect” or “create a session.” These APIs tend to be provided by IoT vendors.
• If your device is large enough, you might host a database. This could be an extremely simple table-based capability or a full-up SQL-queriable installation. Such databases are generally provided by companies specializing in the implementation of databases on stingy hardware platforms (not Oracle-grade behemoths).
• Higher up yet, you may have some business logic executing in the actual phone itself if the device has the necessary computing power; many Things will not. Zonoff, a company we’ll discuss below, gave one example of a device that has resident logic: a door lock. Battery-powered intelligent locks can be programmed to lock at certain times (for instance, a scheduled evening “home shutdown”); those locks might have their own scheduling logic so that they can still work if the power is off.
• Shown at the very top is the Thing’s API. Regardless of how complex the Thing is, other Things and the Cloud have to be able to talk to it, and the API abstracts the functions of the Thing. I’ve used a thermostat as an example in the past; the API for a thermostat might have commands like, GetTemp, StartAC, StopHeat, and so forth. (I’ve completely made those up, in case by chance they happen to look like the commands in some actual API.)

You can argue whether this stack is strictly correct (Is the API really on top? Should it go sideways at the portal?), but it suffices for our discussion (feel free to opine in the comments). And any specific Thing may differ from this general view. So don’t take it too literally.

As we’ll see, some systems allow a level of local interconnection without going all the way to the Cloud: they provide a local Hub instead. Zonoff is a company that follows this model. In a completely connected house, for example, they observed that a smart light switch that has to communicate with the Cloud to operate will work too slowly (not to mention the fact that internet connectivity isn’t ubiquitous or reliable enough yet for such mission-critical features).  A Hub in the home allows response fast enough to let the light switch operate at the speed we expect.

I show a Hub as containing potentially all of the pieces that a Thing has, except for the API part. Yes, there will be low-level APIs for communications and such, but the API I’m referring to in the Thing is the abstraction of Thing functionality. A Hub isn’t a Thing, so it doesn’t have Thing functionality, so I’ve omitted that API block.

More generally, the Thing will communicate with the Cloud. If there is a Hub, then communication might go via the Hub and/or the Cloud. For example, Zonoff can have a phone app communicate with the Hub via WiFi while you’re in the house, but automatically switch to talking via the Cloud once you’re outside and out of Hub range.

• Once you’re in the Cloud, you’re dealing with hardware and services provided by the Cloud Provider. That means the OS and resource management (hard disk, RAM, I/O), databases, and communications. But here again we can abstract the communications and resource management so that the Thing and the Cloud can talk at a higher level.
• Above this are the business objects that can be used to write business logic at an abstracted level. Business logic is almost always custom – this is where much of the end system differentiation comes from. But some companies provide abstracted business objects so that system programmers can stay at a high level, within the semantics of the Thing and its capabilities, rather than having to build a library at a low level first.

  If you’re a ThingMaker, bear in mind that, just because a company provides business objects, that doesn’t mean they have an object that abstracts your Thing. They may not yet have had customer or partner requests for what you provide, or it may be in the pipeline or on the wish list.

• Finally, atop it all, is the Content. This may refer to content that already exists on the internet or content created and saved via the Thing and its associated apps.

A quick note on APIs, by the way, since there can be a lot of them. Much of the business logic, whether done on the Thing or in the Cloud, is executed on a virtual machine (VM). I had a hard time deciding where to put the VM in the figure – at some point you have to start being accurate about what’s over what, and I don’t want to overstate the accuracy of the stacks I’ve drawn. So I’ve left the VMs out, but bear in mind that providers often include those as part of their abstraction infrastructure.

Some of the vendors provide a Platform as a Service (PaaS) model. This includes everything that you need (or that they think you need) for the Cloud, and you’re working in a “protected” environment.

Over on the right of the drawing are the Terminals, simplified as phones and computers (desktop, laptop, or heck, even super). Tablets would fit somewhere between; that fight is obvious and left to the reader. Some companies provide frameworks for writing apps in particular, although writing the app (or application on a full-up computer) remains the job of the system designer (typically a ThingMaker). The main question is the level of abstraction and the libraries available for making it easier to do.

Picking Up the Pieces

Given all of these pieces of the IoT, what are the options for putting it all together? Well, it depends on how much you have already assembled. Some companies try to be comprehensive; others try to focus on a selected part, like databases or communication abstraction. I have identified a few companies to use as examples; I’ll summarize what they do and then try to bring it all together in a Mother of All IoT Tables. Okay, maybe not Mother; perhaps Aunt or Uncle.

• Ayla Networks: we covered them already, and they cover the software aspects of the entire system (minus the Hub), down to the driver level on the Thing.
• Electric Imp: This company makes an actual hardware module (the Imp) that can be soldered permanently down into a Thing; alternatively, the hardware is available housed in an SD card that can be moved from Thing to Thing. They have a unique way of authenticating a phone and a device: you enter a password into the phone app, and then the phone screen flashes a code that the Imp light sensor detects (they call this “Blink-Up”).

  Programming on the Imp is done using the Squirrel language, and programs are compiled and run on the Imp itself.

• IFTTT (apparently pronounced “ift”): It’s actually hard to tell in detail what these guys do, but at the surface level (which is all they provide on their website), they’re a high-level language for executing business logic. Their primary focus appears to be social media channels (you can use events on one to spur events on another, for example). I couldn’t get much more info since they didn’t respond to my request for more detail.
• Imagination Technologies: we mentioned them in our prior coverage as well. They provide end-to-end pieces that include hardware IP and content.
• ITTIA: This company provides a database capability for Things. Their solution is scalable so that you can have anything from an extremely minimal implementation with perhaps nothing but a table or two and no query capability up to a full-up relational setup with full SQL capabilities optimized for the small platform.
• Xively (pronounced “Zively,” but Zively is a separate company… don’t be confused): This company bills itself as providing a layer of adaptation over the Cloud specifically for the IoT. They’re largely resource- and communication-centric; they’re not so much focused on the business objects and logic, although they do play there.
• Zonoff: This company builds system pieces for the intelligent home. In particular, they provide software that allows “controller” functionality to be designed into a number of always-on home appliances like TVs and routers. Part of their role is to try to abstract out communications, since there are many protocols out there that might be used, either within the home or over longer distances. WiFi is common, but not the only thing being used in the home, so Zonoff has their own radio architecture that attempts to bury this complexity.

  Zonoff also offers a Hub, although in the long term they see this functionality as sliding into these other always-on devices. For now, they sell this to the platform providers (since Zonoff doesn’t sell directly to consumers).

The following table attempts to show which pieces from the drawing above are covered by which companies. At the very bottom are the things that either the Cloud provider must handle or that the ThingMaker will have to create. Note that, absent all of these offerings, the ThingMaker would have to do everything. So, for the ThinkMaker row, I’ve focused only on the things that have to be done even given a rich offering of IoT pieces.

A Jungle

It also bears noting that you will often hear that there are no standards for the IoT. Well, depending on what you’re talking about, that may or may not be true.

At the low levels, there are tons of standards. And in some cases – take HTTP, for example – it may not be obvious how they fit into the function being performed. But at these low levels, everyone is following protocols that already exist – trying to define new ones would slow development dramatically. And yes, you may be doing things that weren’t envisioned when HTTP was first devised, but it’s a good way to communicate with internet-related systems, since all browsers understand it. So it and the many communications standards are leveraged to the hilt.

Of course, not everyone thinks the low-level stuff is good to go. The MEMS Industry Group recently hosted a webinar where two new additions to the panoply of wireless network sensors were laid out. One is OpenWSN and defines a stack starting with 802.15.4e-2012 for timeslotted channel hopping, moving up to 6LoWPAN, RPL routing, UDP, and CoAP (Constrained Application Protocol). Missing in that stack is a scheduling standard for assigning time slots and channels; 6TSCH is proposed to slide between 802.15.4e and 6LoWPAN for that purpose.

But at the top layers – APIs, business logic, protocols for sending semantic-layer messages between Things and the Cloud and Terminals – it’s wide open. Lots of folks doing things their own way. Zonoff mentioned that many businesses prefer it this way – standards would lead to the commoditization of the technology.

And it’s probably fair to say that, at this point, while the technology is shaking out and everyone is experimenting with the best ways to do things, leaving it open for unconstrained exploration is probably a long-term good thing for technology. It’s also, of course, a good thing for providers, since it allows them to create walled systems that won’t interconnect with other systems – you’re locked in (either as a developer or as an end consumer). And businesses like it when you’re locked in (there’s a fine line between “sticky” and “stuck”).

But I see this evolving in the same way that the internet did. In the early days, when things were wild and wooly and scary for your average computer non-geek, having a walled garden such as that provided by AoL was a good thing. But eventually, the streets got cleaned up and browsers started to find better ways to present the content and ward off questionable interactions (largely a security thing), and so the people in the walled gardens started to see other people playing in the streets and, ultimately, they wanted to go play there too.

Likewise, for now, these IoT walled gardens can help an intrepid developer to get things done more quickly – at the cost of buying into a particular system. But sometime in the future, I see folks – consumers not least – getting more restless. So attempts to harmonize some aspects of this high-level stuff are likely in the offing, but not for now.

That’s my meager attempt to deconstruct the pieces of the Internet of Things in a more nuanced fashion than we’ve done in the past. As specific topics in this area arise, we’ll come back and deconstruct yet further. Feel free to suggest alternative ways to organize this stuff.

More info:

Ayla Networks

Electric Imp

IFTTT

Imagination Technologies

ITTIA

Recent ITTIA IoT announcement

Xively

Zonoff

Recent Zonoff SDK announcement