Architecting IoT infrastructure

In the last Gigaom Research blog post,  IoT use cases in the smart agile business were discussed.  This post will cover architecting the IoT infrastructure…Enjoy!

While smart devices undoubtedly help, IoT is not simply about what it can connect, individually, to the internet. Rather, successful business use cases enable a broader problem to be solved (saving money or reducing risk) or service to be delivered (increasing revenue).

From an architectural perspective, configurations for IoT comprise the following key elements:

• A sufficiently large number of physical objects possessing similar domain attributes and that could benefit from some kind of centralized coordination and control and either contribute to or benefit from shared and distributed as well as enhanced intelligence. For example, these could be patients in a hospital, trees in a forest, animals on a farm, or cars on a highway.
• Embedded passive sensors or active devices. Embedded devices of all shapes, sizes, and levels of complexity act as the fingertips of IoT. Devices can be passive or active, the latter potentially including some basic processing capabilities. These use a variety of message and event passing protocols, for example lower-level MQTT1 or higher-level XMPP2 for asynchronous message exchange.
• Local processing. Local hub devices enable events to be collated, interpreted, and delivered to the cloud in an efficient and secure manner. For example, image information can be processed or threshold rules tested locally before sending on relevant data or events. While this could be a locally installed computer, it is worth calling out smartphones as potential hubs, as they combine networking, processing, sensors, and human interaction.
• Multi-protocol gateway capabilities. Given that the number of protocols and data types in use across individual devices and sensors is still diverse and occasionally proprietary, gateway technologies from the likes of Wind River, Intel, Cisco, and Freescale enable events to be collated. Gateways can also build in security and manageability features, which are often lacking in individual sensors and devices.
• A connectivity layer of suitably low latency. Providing the backbone of IoT, the connectivity layer encompasses wired and wireless communications protocols from device-specific ZigBee or Bluetooth through Wi-Fi and 2G, 3G, or 4G mobile to local networking and the wider internet. Note that not all use cases require objects to be constantly connected.
• A scalable storage capability. Given the event-driven nature of IoT’s sensory network, storage requirements can be difficult to define in advance and are easy to underestimate. Generated events can be stored and pre-processed locally, for example in a relational database; online storage options using more-scalable NoSQL approaches include Xively,3 TempoDB, and Aeris.
• Cloud-based processing. For IoT to be about more than simply remote monitoring and control, it requires a scalable computing capability to collate, interpret, and analyze potentially large volumes of information. While this capability can be delivered on in-house servers (particularly if security or latency are concerns), the scalability requirement can make cloud-based services such as Amazon Web Services (AWS), hosted Hadoop, or Splunk a more attractive option.
• A management and control system. This enables centralized monitoring of physical objects as well as rules to be set around what to do when certain events occur. It may also enable control of end-point devices, for example enabling adjustment of heating and air-conditioning units in a building. “Thing management” also needs to incorporate such topics as firmware updates to the embedded devices at the edge.

By looking at these elements as an ensemble, we can see what differentiates IoT from previous trends and how it will continue to develop and mature. Each of the above incorporates a number of constraints and trade-offs. For example:

• Embedded devices may be small and low power, but smaller devices can only perform more-basic functions.
• Cloud processing may be highly scalable, but it requires a great deal of power and can become cost-prohibitive.
• NoSQL approaches are good for high-throughput data processing, but they are less resilient than more-traditional data-management techniques.

The result is that system and solutions designers need to choose the right architectural approach that takes these constraints into account. Nothing is stopping a manufacturer from creating a new type of device that combines some of the above — for example, an embedded device with some pre-analytical capability. Equally, an organization may choose to host its own scalable processing or analytics capabilities in an enterprise data center if it can define the requirement sufficiently well. Indeed, as is the case with web-based applications, it is likely that organizations will trial IoT use cases using cloud-based services, retaining the option to bring them in-house at a later point.

While all options are open, in practical terms a number of architectural models are emerging that satisfy the majority of current IoT use cases while delivering on the sensory-network principle of real-time responsiveness, as follows:

• Ultra-thin client, hub-and-spoke model
• Front-loaded embedded devices with local pre-processing
• Smart client, enabling peer to peer

The next Gigaom post will discuss what is needed to deliver successful IoT use cases…stay tuned.  And to learn more about how Wind River is addressing the opportunities and challenges created by the IoT visit our IoT microsite.