Cloud-device Integration for the IoT

The Internet of Things (IoT) is bringing unprecedented levels of intelligence to embedded control. Where devices used to be isolated, the IoT bring them together into a system of systems. That provides the ability for devices to cooperate with each other and interact with other services to provide much greater performance, responsiveness and uptime.

Users can take advantage of the massive compute power of the cloud to let machine learning, data mining and other technologies work on the streams of data provided by all the IoT devices the application serves. Those IoT devices need not be designed specifically for the application. Cloud-based system can take advantage of data-wrangling technologies such as Spark and Hadoop to incorporate real-time and historical information from numerous sources. This makes it possible to perform correlations across many sources and, in doing so, derive valuable insights. With such power, complexity is perhaps inevitable.

A key issue with IoT application delivery lies in the diversity of components that make up each solution. The IoT application needs to capture readings from different types of sensors, such as temperature, motion and air quality. Even for the same type of sensor reading, the data may come from devices that are provided by a variety of manufacturers or based on older hardware that was not designed for the IoT.

Consider an example IoT project that involves monitoring the temperature inside each room within a hotel. Each room could have three sensors, each able to monitor temperature. One by the door may have its temperature sensor included as a part of a fire-alarm module, another close to the bed may be associated with the in-room air-conditioning controls, and the other in the bathroom installed as a dedicated unit as part of the IoT upgrade.

The software that obtains readings from each type of device needs to take into account the way in which each sensor is calibrated and its data obtained. Some devices may send data at regular intervals, based on a change in conditions beyond a programmed threshold or on demand by a cloud-based application. And they may each use different network connections – some wired, some wireless such as Bluetooth or Zigbee – to relay the data. The application needs to take account of this variability. But that is not all.

Energy consumption is a primary issue for many IoT devices. The most common way to maintain a long battery lifetime is to minimise the activity of high-energy systems such as wireless communications and the core microprocessor. These subsystems are maintained in a low-power sleepfor much of the system’s lifetime. . For short periods, they wake up, handle a task before returning to sleep again. The result is a low duty cycle. Perhaps for no more than 1% of the system’s lifetime is it in a fully waking, high power-consumption state. During the remaining 99% only systems needed to maintain system state, such as real-time clocks, are powered. Using such a design, an IoT node can survive for years on a single battery charge.

Many microcontrollers (MCUs) now incorporate hardware state machines that make it possible for important sensors to wake up periodically, triggered by the real-time clock, and take readings without waking the host microprocessor. Some systems may take a predetermined set of readings before the microprocessor is woken to perform processing. Others may program thresholds into the sensor logic so that large excursions trigger an immediate reaction.

A control application running in the cloud may have requests for data that it wants from the device or to send it a command to change its state. But the device may not respond for some time because the need to ensure a low duty cycle will mean it will be in a low-power state when the command is issued. The application requires logic to ensure that its understanding of the state of the device is consistent with reality.

In the initial phase of the IoT, integrators found they had to build their own software infrastructure for cloud integration, using custom protocols or remote procedure call (RPC) techniques. Typically, they would use their own data centres or rented server blades in dedicated facilities on which they ran applications that would receive data from connected embedded devices, push the information into a central database and run applications to present data to users and perform analysis of patterns.

The integrators would be responsible for ensuring resilience and high availability and to deal with the complexity of an environment where devices are not permanently connected to the network. One way to achieve that is using the concept of device shadows. These are cloud-stored documents that cache information on device state from its last reports and any pending changes.

Although applications can manage device shadows themselves, it is a task that is more easily managed if devolved to a service layer that can offer a standardised interface across many types of devices. This is one of the many capabilities now handled by cloud infrastructure offerings such as Amazon Web Services, IBM Watson IoT and Google Cloud.

Another service performed by cloud-infrastructure platforms is protocol mapping. The cloud evolved around the widespread use of the TCP/IP protocol and the services that it can carry. Although it is a stateless protocol, the HyperText Transport Protocol (HTTP) used for many cloud-based services, runs on top of the state-oriented TCP layer, largely because of TCP’s widespread support. However, few IoT devices have the resources to implement a full TCP/IP stack to allow direct communication with cloud applications. Defined by an Internet Engineering Task Force (IETF) request for comment, the Constrained Application Protocol (CoAP) streamlines HTTP to be more compatible with resource-constrained devices and removes the need to use the TCP layer.

CoAP employs a 4byte header with compact encoding to support protocols with much shorter packet lengths than those normally provided by backbone Ethernet connections. A common alternative to CoAP that has attributes that are seen as more suitable for many IoT implementations is the Message Queueing Telemetry Transport (MQTT) protocol developed by IBM. This can run over a variety of packet formats, such as Bluetooth and Zigbee as well as TCP/IP. In contrast to the client-server model of traditional HTTP web services, MQTT underpins a publish-subscribe model. This has the advantage of minimising individual requests to an IoT device.

Figure 1. A gateway mapping MQTT and CoAP – Image copyright of Premier farnell

Figure 2. Example of the MQTT pub/sub model – Image copyright of Premier farnell

To ensure consistency for data transfers across different platforms, cloud platforms employ the JavaScript Object Notation (JSON) format. To send data to the cloud, a device must first encode the data it has into a JSON representation and then use that as the payload for CoAP, HTTP or MQTT messages. Implementers have a choice: have the end devices perform this task or rely on gateways to take care of the process. In systems with extensive legacy hardware, a gateway will often be the preferred choice. The gateway can collect data using the proprietary or pre-IoT standards used by the devices and convert data to and from the JSON representation, as well as acting as a proxy for any commands received from the cloud. The gateway implementation will determine whether those commands need to be converted and relayed in a form the device can understand.

Devices designed for the IoT may include their own software stacks to take care of JSON conversion and interactions with the cloud. Support for JSON and network interfaces may be incorporated into the core real-time operating system (RTOS) and accessed using programming languages such as C. A technique employed by some IoT integrators and supported by cloud-infrastructure providers is to implement a virtual machine on each end device that is optimised for IoT-cloud integration.

Figure 3. Example of a sensor output in JSON format – Image copyright of Premier farnell

Device drivers implemented on each IoT device platform are used to translate commands from the virtual machine into forms that the underlying RTOS and firmware can understand. The firmware takes care of optimising energy consumption and low-level timing and provides a standardised set of services on which the cloud layer can rely.

Development in a cloud environment provides a richer array of programming tools compared to the traditional embedded environment. Today, languages used for cloud programming tend to be designed to run in a managed-code environment. Rather than being compiled, the code is interpreted at runtime or, if it offers greater performance, just-in-time (JIT) compiled. Whereas embedded developers generally have a restricted selection of languages, primarily C and C++, cloud developers have access to a rich variety of languages, many of which are optimised for specific needs. Whereas Java and Python support many application requirements, Hadoop extends Java to make it easier to spread a data-processing workload across many compute nodes.

Although both embedded and cloud programming imply the use of cross-development resources, developers writing code for servers can often use virtual-machine technology to build a scaled-down version of the target environment on their own machines. Typically, embedded developers need to develop code separately from the target and run tests after each edit-compile-download sequence, which increases turnaround time. Middleware environments that support managed-code languages help streamline development by making it possible to prototype code on a local virtual machine and so bring similar benefits as though experienced by cloud developers.

Thanks to the availability of cloud-infrastructure services, integrators now have access to an armoury of tools that make it much easier to assemble full IoT solutions. Reaching down to the device layer, these cloud-oriented services ensure that the complexity of deployment is much reduced and that integrators can harness the full power of the IoT.