The next big challenge in IoT evolution: Getting the protocols right
In this article you will learn about some of the considerations that need to be taken into account for leveraging different protocols while writing applications for the Internet of Things (IoT)
Software developers face a wide range of protocol choices in creating applications for the Internet of Things (IoT). These applications need to be able to consume information from a large number of devices. The choice of protocol depends on the use case and where the application will be staged in the software environment.
IoT devices in the field often communicate using a new generation of protocols including AMQP, MQTT, and CoAP. This data is often aggregated by gateways, presented to cloud data stores, and then connected to enterprise or mobile applications. In some cases, the developer should consider a multi-protocol strategy for different parts of the architecture, according to Tom Gilley, CTO and founder of Wot.io, an IoT data service exchange for connected device platforms.
Wot.io deals with all of these protocols using a component model that offers a choice of connecting to any data source and then routing and acting on the data in the desired manner. Connected device platforms include everything from legacy industrial, M2M, cellular and Internet connected devices. Gilley said , "One of the keys to agility lies in blending the information from the IoT with web services."
One of the keys to agility lies in blending the information from the IoT with web services.
Tom GilleyCTO and founder of Wot.io
IoT applications can provide value to enterprises by improving the business decision process by triggering events, generating reports, or driving business dashboards. In other cases the value of the IoT application might be for generating reports or sending alerts to IoT device users. Each stage in this IoT application might leverage different protocols.
The complexity of IoT infrastructure
When developing IoT applications, there are a wide variety of back end platforms to choose from including AT&T's M2X, Alcatel Lucent's Mformation, Jasper, PTC's Axeda, ThingWorx , or Qualcomm's DeviceHive. These are in turn connected to data stores on the back end, these applications need to support big data using MongoDB, Hadoop, Postgres or ScaleDB, a variant of MySQL for high velocity storage.
Gilley said, "We found that it makes sense to use a data store because the operational side has to characterize the database and becomes uncomfortable with a non deterministic load. We try and work with them on some kind of replication by batch or in some cases have a message bus feeding this. "
Web automation platforms like Bip.io or IFTTT can generate event triggers to send alerts or reports based on individual events or thresholds. These different platforms are often linked to various data aggregation and reporting platforms to generate reports, update dashboards, or trigger events. These include JReport, Tableau, Pentaho, and Splunk. The IoT application could be developed to leverage different protocols across the different components of the aggregate solution.
The IoT protocol landscape
The Advanced Message Queuing Protocol (AMPQ) is a wire protocol that provides a message bus architecture. Gilley said it is good for high velocity, low latency messaging. It is good for publishing to the message bus and making it available to the data service or Web applications. It allows for intelligent routing on top of the message bus and a dynamic routing engine creates a publish subscribe model for the data from connected devices to services, whether they are hosted or running on a PaaS.
AMPQ has become popular for high velocity, low latency message and is similar to Kafka, another messaging bus technology. AMQP started off as a protocol for Web services. But its characteristics have made it a good fit for many scenarios around communicating with the devices and the back end infrastructure relating to IoT applications. But the devices themselves need to have good memory and processor capabilities.
Another protocol for device management platforms is MQTT, which was developed by IBM and open sourced to standards bodies. It has become the de facto standard for constrained devices, said Gilley. MQTT is often used between IoT devices and the management platform and in some cases for communicating through adaptors. MQTT is a separate wire protocol for constrained devices with fewer features.
MQTT and AMQP are different technology stacks or protocols. They are related in that they both use messaging bus. It is possible to take MQTT and then go from service to server. AMQP is more popular for server to server scenarios.
Leveraging Web skills for the IoT
Traditional Web developers might be more comfortable building applications using the Constrained Application Protocol (CoAP), which is a lightweight version of HTTP. Both CoAP and MQTT were designed for constrained devices with small memory and processor footprints. The difference between CoAP and MQTT lies in the type of interaction required. MQTT is better at handling time series data from sensors.
CoAP can work better when data can be gathered from devices via queries. "If you are not streaming and want to query every hour of the day, then HTTP or CoAP is a better protocol to choose," said Gilley. For example, CoAP would be a better choice for a thermostat that is queried on a regular basis.
If there is an anomaly in the data or an event that requires more than a single poll, then it is possible to instantiate a streaming scenario that generates a time series or a stream of data using MQTT. Gilley explained, "It might be better to combine the use of protocols depending on the use case."
What protocols have you adopted for creating IoT applications and why did you choose them? Let us know.
