The IoT Triangle

The Internet of Things can be a daunting topic. It involves countless protocols, and allows for many architecture variants. As a result, it is difficult to find a simple, yet still useful mental model for discussing the topic, without glossing over important aspects. In particular, I want to be able to discuss questions like "which protocols are suited for the IoT", "what services should an IoT cloud platform provide", "do we need CoAP support in a browser" and similar questions in a meaningful way. Here is my attempt at such a model. Feel free to comment!

In my Internet of Things reference model, let's call it the IoT Triangle, I distinguish between three domains where different technical requirements apply, different technologies are established, and different quality attributes are relevant. They are: Cloud Services, Smart Screens, and Smart Objects. I'll briefly discuss each of these domains, and then the communication links between these domains. The pink background represents the open Internet with botnets, NSA and other threats, while the grey bubbles represent more controlled "edge networks".

Most people would agree that cloud services will play a major role in the Internet of Things. It remains to be seen which role(s) the cloud will eventually have, but broadly they can be communication-related (e.g. protocol conversion), storage-related (e.g. sensor-feed databases), or processing-related (e.g. analytics).

IoT cloud services may be atomic, single-purpose building blocks that you can use to build your IoT applications. For example, a relay service such as Yaler (disclaimer: Yaler is one of our spin-offs) is laser-focused on enabling access to devices that are servers but located behind firewalls or network address trans-lators (NATs). This is an example of an infrastructure service (IaaS). Another great example is IFTTT. In contrast, other IoT cloud services may provide comprehensive support for building IoT applications, they are IoT platforms (PaaS). Most of the products listed here are in this category. And finally, cloud services may implement complete applications (SaaS). I think there must be examples; do you know of a good one?

This is the realm of powerful data centers and Web services, programmed in Java, C#, JavaScript with Node.js, or one of the newer languages such as Go or Scala.

Some services (IaaS, PaaS, SaaS) are public, others are used solely within orga- nizations.

This is where the smart objects live, the plant sensors, connected oil tanks, bicycles that measure the wear of their brakes and chains, production machines that reconfigure themselves automatically depending on the parts they are fed, etc.

Smart objects may be in places where people live or work, in particular homes, offices and factories. But they may also be in gardens, football fields or moving vehicles. Many smart objects frequently interact with humans. Others, only in rare cases, consider e.g. avalanche monitors, weather stations in the antarctic, or wheat fields with autonomous crop harvesting machines. However, at the end of the day, there is always a human in the loop who somehow benefits from the smartness of the objects, otherwise no one would provide the investment for adding smartness to objects in the first place.

While the cost of adding smartness and connectivity to an object is ever-decreasing, it is still larger than zero and thus remains a key factor in the question whether or not an IoT application is economically viable.

Objects are made smart by augmenting them with embedded systems. Embedded systems come in enormous variety, as they are specifically tailored to the object that they augment. Processing power may range from slow 8-bit microcontrollers with 4 KB (yes, KB, not MB, let alone GB) of RAM to multi-core processors sporting specialized hardware e.g. for digital signal processing.

Embedded systems are mostly programmed in plain C. For a while, C++ seemed to slowly replace C, but this trend has halted. Other languages like Java or C# have only been used in niches; JavaScript in the embedded space is a holy grail for some, a spawn of Satan for others, but mostly missing in action so far; and more exotic languages have been used or are considered for particularly demanding applications (e.g. Ada, Esterel, D, Rust).

In terms of communications, this is where we really have full chaos. With literally two dozen contenders for an industrial Ethernet standard (from Modbus TCP to Ethercat and Profinet all the way to TTEthernet), a plethora of serial com- munication standards (from RS-232 to USB), and a variety of short-range radio technologies (from ZigBee to Bluetooth Smart). Of course, the dream is to unify all of that to a few, complementary IP-based protocols. Then an enormous amount of know-how, algorithms, security mechanisms, and networking code could be reused.

We are far away from that dream state though, and will be stuck with gateways for many, many years to come. And in the case of wireless radios, physics may still spoil the party. It is by no means clear yet how expensive - in terms of power consumption - IP traffic to the most lowly wireless sensor really is, even with IP header compression and similar tricks.

Most interactions of humans with computers go through screens, built into devices like personal computers, tablets, or smartphones.

Smart screens are large enough that they can come with sizable batteries (or are mains powered), so they support powerful general-purpose operating systems like Windows or Linux, and complete IP-based networking stacks.

Smart screens are often programmed in JavaScript with HTML5, as native iOS, Android or Windows apps, or as hybrid apps where HTML views are embedded into otherwise native apps.

The difference between smart screens and smart environments is not perfectly cut-and-dried, there is a grey area. On the one hand, Wearables such as fitness armbands and smart watches can also have screens. Smartphones on the other hand contain an increasing number of sensors. This is why the smart objects and smart screens domains overlap.

Note that a user often carries a smart screen, say a smartphone, while she is moving around in an environment containing smart objects. This means that the user can interact with the environment directly, e.g. by physically closing a door, indirectly by using the smartphone to issue a remote control command to the door via short-range radio, or even more indirectly by sending a remote control command from the smartphone to the door via a cloud service (e.g. for authentication and authorization purposes). This is a reason why so many architecture variants are possible for an IoT application.

Most IoT technology discussions relate to only one of the above domains ("can/should I try to program my smart objects in JavaScript?"), or to only one of the above links between two domains ("should we implement CoAP support in our cloud service, for accessing smart objects?"). I have given these links (the tri- angle edges) different colors, as I haven't found really good names for them yet.

To simplify the model down to its essentials, here the "light" version of the figure at the beginning of this post:

Communication between smart screens and cloud services has pretty much con- verged by now regarding the used technologies. Smart screens act as HTTP clients that access RESTful Web services in the cloud, server-sent events (SSE) can be used to push data from the cloud to the clients, Web Sockets are used for bi-directional communication between cloud services and smart screens. Below the application layer, IP and TCP are used.

Whether smart screen apps are HTML5 apps, hybrid apps or native apps, they usually access some public Web services using HTTP libraries. Alternate proto- cols are rarely attractive, as they would have to be implemented in JavaScript to be truly cross-platform (HTML5 is a platform of its own and only supports JavaScript). To avoid this, protocol conversion would have to be pushed back to the cloud (e.g. we've developed an OPC UA to JavaScript proxy years ago), but this just means that the green link firmly stays in the "TCP plus HTTP" camp.

In practice, smart screens are able to directly communicate with the smart objects in the vicinity mainly through two technologies: WiFi and Bluetooth Smart (aka Bluetooth Low Energy, BLE). WiFi has far higher bandwidth, but typically con- sumes more power than BLE and WiFi modules cost more than BLE modules. For this reason, video and audio streaming are done through WiFi, while occasional sensor reading or remote control sending is preferrably done via BLE.

WiFi and BLE are currently the only cross-platform short-range wireless techno-logies, as they are supported on all modern iOS, Android and Windows devices. Note that iOS devices also support classic Bluetooth, but require a proprietary Apple chip for authentication on the other side, so classic Bluetooth is not cross-platform in practice. With the introduction of the iPhone 6, NFC has also become a cross-platform technology, but due its very short range of only a few centi-meters, it only supports highly specialized use cases.

Because of the tremendous variety of embedded systems technologies, and of "edge" network technologies (white bubbles around the triangle corners), gateways can rarely be avoided between smart objects and cloud services. A gateway may often be acceptable, if it allows to serve many sensors and actuators. However, no one wants a gateway in her home for the home security system, another gateway for lighting control, another gateway for garden monitoring, yet another gateway for the aquarium, etc. Therefore we need enough standardization at least within one radio technology to allow sharing of the same gateway for different applications, from different vendors. Whether successful standards will be open and come from standards bodies like the Bluetooth SIG, or will be proprietary and come from vendors like Apple (i.e., HomeKit), is anyone's guess at this point (late 2014).

Even if WiFi is used, and therefore a generic router (WiFi access point) can be used rather than a gateway that performs higher-level protocol conversion, a non-obvious issue remains: smart objects are often naturally treated as services (e.g. a garage door service), rather than clients (or as both servers and clients). Such servers are normally situated behind firewalls and NATs; even the advent of IPv6 does not seem to change this fundamentally. This means that the servers are not directly visible to clients (e.g. a device management service in the cloud). Clients cannot see, and therefore address and access, these services. There are several approaches for solving this problem, with their respective architectural advantages and disadvantages. I'll come back to this topic, which we've been confronted with in multiple customer projects, in a later blog post.

As you can see from this brief discussion, the situation for the green link is relatively clear, there is little pressure for IoT-specific protocols on this link.

As long as Google and Samsung do not introduce native hardware support for THREAD in Android phones (and convince Apple and Microsoft to follow suit...), the blue link is defined pretty much by the available cross-platform technologies, which means WiFi and Bluetooth Smart. As Bluetooth Smart is pretty new and not IP-based, this warrants some more discussion in later posts.

The open question mostly centers around the red link, because of the impedance mismatch of the IT domain (cloud services) and the many standards and would-be standards in the embedded domain (smart objects). There is also a lot of interest in extending various object-to-object protocols, possibly even with real-time guarantees or other quality of services assertions, from controlled edge networks out to the Internet at large - which is a wild and uncontrolled environment (pink background) in comparison. Things are also getting interesting if we look at end-to-end security, which of course begs the question what exactly the endpoints are (sensor? gateway? cloud service? browser?).

With this simple reference model, I hope it will be possible to discuss many architectural questions around the Internet of Things. By adding details to the model and by assigning particular technologies to its elements, specific architectures can be derived and compared. I intend to use this not just for our Limmat architecture, which is the main focus of this site, but possibly for other IoT-related blog posts as well.

(This post was edited in January 2015, e.g. renaming Smart Environments to Smart Objects and making the background red, well, pink, to indicate its uncontrolled nature.)