What are the next key issues for implementing IoT?

The IoT’s new opportunities and new challenges

The concepts behind an IoT infrastructure are not exactly new; typical implementations comprise a computing resource that makes decisions based on sensor inputs to drive actuators and user interfaces. Control systems have been doing this for decades – or centuries, if we start with James Watt’s steam engine speed governor of 1788.

Yet the IoT differs profoundly from traditional control or communications systems, as evidenced by its growing impact on our working and personal lives. It is increasingly pervasive, with IoT components deployed throughout our cities, our homes and even our bodies. Performance is driven by the increasingly large number of sensors in IoT schemes, and cost-effective cloud-based computing resources capable of analysing the high volumes of data generated. The results are giving us new depths of insight into what has happened, and even more usefully, what’s about to happen.

While a traditional control system may content itself with activating a motor, an IoT implementation could log motor vibration trends and warn of imminent bearing failure. It may also be monitoring nearby presence detectors and deciding whether the motor should be activated at all.

The IoT’s ubiquitous growth is being driven by several factors; cheaper, smaller sensors, more choice in local and longer-distance wireless technologies, and developments in Cloud computing. However these are disparate technologies, not being developed as a single, end-to-end IoT solution. This raises challenges for IoT infrastructure designers in addition to those created by the components themselves.

In this article we review these key issues, and discuss the points that designers should consider while planning an IoT implementation. Let’s start by highlighting the major elements of an IoT system, and then look more closely at the issues related to each element.

Fig.1: The IoT offers improved insight and control for all aspects of our social and working lives

End-to-end IoT infrastructure

At the highest, simplest, level, an IoT implementation comprises edge devices, wireless networks, gateways, the Internet and a centralised information processing resource. The edge devices, broadly, are either sensors or actuators. The sensors capture real-world data, which is passed across the wireless networks to gateways. In some systems, data from groups of closely collocated sensors may be concentrated by local platforms before being forwarded to gateways. The gateways package the data for exchange across the Internet with the centralised, typically Cloud-based processing resource.

This acts on the data received from all the sensors across the entire IoT infrastructure, maybe including some without any immediately obvious interrelationship. Actuation decisions resulting from centralised processing are transmitted back across the Internet, through the gateways and local networks, to actuator-type edge devices.

Complex items such as video cameras or mobile phones can act as edge devices, but much of the IoT’s penetration comes from large arrays of small, low-cost, ultra-low power sensors detecting real-world parameters. HVAC systems provide a typical example, as they use sensors to monitor temperature, pressure, humidity, air velocity and gas. We’ll start by looking more closely at these edge devices, and then continue by similarly reviewing the other specified IoT components.

Edge devices, actuators and sensors

Actuators fulfil a wide variety of functions, of which lighting control is an important example. The increasing dominance of LED technology for illumination is due to LEDs’ easy controllability as well as their efficiency, long operating life and other performance benefits. Edge actuators in a building’s lighting scheme could comprise controllers with dimming and switching functions managed remotely through industry standard buses such as DALI or DMX. Building management systems can use inputs from room occupancy and daylight level sensors to dim these controllers intelligently, significantly reducing energy waste in large commercial or industrial properties.

An input or sensor-type edge device comprises the sensor itself, together with an embedded processor, communications capability, and a power source. An engineer selecting or developing these components faces several interrelated design decisions. Most relate to the individual device components, but one critical factor – power consumption – impacts the entire device design. We’ll return to this later.

Firstly, the sensor must be correctly matched to the process it is monitoring. If the variable is temperature, small IC devices like the Texas Instruments LM35DZ/NOPD are available – but is the selected part calibrated for the correct temperature range, is it sufficiently accurate and does it respond to temperature changes fast enough? Then, any device that complies with these process requirements must do so while being resilient to environmental challenges such as moisture or dust ingress over long periods. It must also be attractively priced and easy to install, especially when significant quantities are involved.

Fig. 2: Temperature sensor IC

Fig.3: Human body sensors

The device’s processor function can be fulfilled by embedded microcontrollers that are as small as 2mm x 2mm, yet have the full capability of a 32-bit microcontroller. Processing power is important, not only to package the sensor data for local network communications, but also to provide some preliminary analysis. Loading on the central resource can be significantly mitigated if edge devices only send data when a significant change occurs – reporting by exception – rather than constantly reporting a non-changing value.

Further processing power, or even additional hardware, may be deemed necessary for security; assuring the integrity of the products and the data they exchange. Tiny crypto-engineered hardware devices are available, together with the tools necessary for adding security into any digital system.

The communications interface depends on the wireless local network protocol chosen; a choice influenced by several trade-offs involving data rates, range, power demand and interoperability. We review these network protocols below – but first, it’s time to look at the all-pervading issue mentioned above; power consumption, and how to minimise it.

The wireless edge devices being discussed can only obtain power from internal batteries or by energy harvesting. In an unattended environment, battery replacement is undesirable and expensive, not only through unit costs, but also because of the labour needed for access and replacement. So, power consumption should ideally be reduced sufficiently to allow an energy harvesting solution; failing this, battery life should be extended to weeks, months, years or even decades if possible.

The quest to cut power demand can start by reviewing microcontroller datasheets. However, these should not be relied on, as many factors influence the real-world level of power drawn. Increasingly elaborate power mode options can make finding an optimum approach difficult, especially in balancing the device’s active-mode performance with its speed in returning from a sleep mode. Also, how much of the workload is the microcontroller handling? Is it looking after analogue-to-digital conversion and pulse-width modulation as needed for sensors, and communications protocols? Do integrated memory subsystems, extensive clock gating or advanced process technologies contribute to power economy?

As mentioned, the choice of network protocol is dictated by a project’s specific requirements and priorities. However, this choice significantly affects the edge device’s power consumption. A 54Mbps WiFi network is far more power-hungry than an IEEE 80.15.4 implementation like ZigBee.

Other real-world factors include the data processing load, and whether data is generated in short bursts followed by extended periods of inactivity. If so, the processor’s sleep mode current drain becomes critical, especially if the device is relying on energy-harvesting for power. All harvesting options are similar in providing tiny amounts of energy, which must have an opportunity to accumulate while the system is sleeping to be usable. Conversion to a higher voltage level is often also required.

Precious harvested energy can be further preserved by minimising the overhead in bytes of any transmitted data package.

If the device’s power drain level permits, three popular energy-harvesting options are available. The first is solar energy, where ambient light energy is converted to electrical power using miniaturised solar cells. Secondly, kinetic energy from lateral movement, rotation or vibration can be harvested using electromagnetic or piezoelectric devices. Finally, energy from close-distance temperature differences can be converted to electrical power with Peltier elements.

Additional, less widely used, ambient energy sources include electromagnetic waves as well as chemical and bioelectric systems.

Local wireless network choices

As mentioned, apart from the imperative for minimised power, local wireless network choices revolve around data throughput, transmission range, reliability, security and interoperability.

With current projections of 50 billion devices by 2020, Wi-Fi remains as a dominant presence. It offers secure, high-bandwidth connectivity and Internet access with data rates to 54Mbps, together with transmission ranges to 100 metres at 2.4GHz. However, Wi-Fi is more power-hungry than other 2.4GHz options - although newer, embedded variants such as TI’s SimpleLink Wi-Fi trade lower performance for reduced power demand; a device can run on two AA batteries for over a year.

Bluetooth is popular in lower-power applications, with over three billion installed units. Bluetooth devices can power down when inactive to reduce power drain. Operating in the 2.4GHz ISM band, which is available without licence in most countries, it throughputs data in the 2Mbps range; less than Wi-Fi, but still sufficient to handle multimedia and other higher data rate applications.

Bluetooth low energy (BLE) is a variant of Bluetooth designed for ultra-low power applications such as wearable sports and welfare products. Its connectionless protocol significantly reduces transmission on-time, and BLE power requirements are fractional compared with traditional Bluetooth implementations. A coin cell can support over a year of BLE operation.

ZigBee is a practical example of the mesh-based, highly reliable network protocol mentioned earlier. As well as reliability, this cost-effective standard offers security, and achieves low power consumption through low data rates. RF4CE is a higher-performance variant of ZigBee.

ANT is a simple, low cost and ultra-low power alternative to BLE, popular in sports, wellness management and home health monitoring applications. With data rates of about 1Mbps, a range of a few tens of metres, and years of life from a coin cell, ANT supports mesh as well as tree network topologies. Its technical appeal is only offset by Bluetooth’s 3B installed base.

The relative performance of the various available protocols depends partly on wireless frequency issues. The most popular bands are sub-1GHz, 2.4GHz and 5GHz. As range approximately halves as frequency doubles, longer-range applications may require protocols using sub-1GHz frequencies. However, data rate also diminishes as frequency reduces, so 5GHz becomes appealing for designers needing high throughput, if they can accommodate the reduced transmission range.

2.4GHz is a popular compromise, and as such has been embraced by consumer technology, with resulting congestion issues. Nevertheless, it remains popular through offering a reasonably high data rate, adequate range, no duty cycle restrictions, and because the 2.4GHz band works world-wide.

All the above standards are designed for situations where the sensors are metres or possibly tens of metres from the gateway. However, applications like agricultural monitoring, fleet tracking and many others deploy sensors that can be many kilometres from their managing gateway. Two technologies are currently competing for this vast long-distance opportunity; cellular connectivity based on a new IoT radio technology called NB-IOT, and non-cellular, low-power wide-area (LPWAN) network technology from providers such as the LoRa Alliance and SigFox.

LPWAN is a good fit for IoT, with nodes that can be up to 10km from the gateway. Power consumption is ultra-low, with node batteries lasting up to 10 years. LPWAN is also ideal for the low throughput requirements of IoT data packets, typically a couple of hundred bps or less.

NB-IoT offers low power consumption coupled with carrier-grade reliability, privacy and security, and support for up to possibly 100,000 connected devices. Interference is low, and NB-IoT can be configured on an LTE network with just a software upgrade.

Applications like agricultural monitoring deploy sensors that can be many kilometres from their managing gateway. NB-IOT and LPWAN technologies are being deployed in these type of applications.

Gateways

Gateways exchange data from arrays of sensors and actuators over local networks that cover a few metres, or possibly, as we have seen, a few kilometres. They package this data into IPv4, IPv6, cellular wireless or other long range wireless protocol for Internet communication with information processing and analysis machines in the cloud, possibly alongside data from many other gateways over a wide area. The gateways also receive configuration and update information for themselves and their client sensors, as well as control commands for edge actuators.

In communicating with edge devices, the gateway may need to interface with a machine code environment or a simple RTOS system. It must interact with this environment to exchange data, query the devices to determine software revision level, and then deliver security fixes and code updates as needed.

Many development kits, platforms and SBCs are available to help developers make a start on IoT gateway development. Development kits based on products such as the BeagleBone Black or Raspberry Pi include integrated interfaces for Wi-Fi, Bluetooth or other wireless protocols, as well as an Ethernet option for Internet access. They allow engineers to start development out of the box, so they can immediately focus on the application-specific, revenue-generating aspect of their new IoT product design.

The element 14 community offers many resources related to this process. For example, there’s an article called ‘BeagleBone Black IoT Project Bundle’ that pulls together everything needed for an IoT experiment or project – from the sensors, through the BeagleBone Black-based gateway, to accessing a free layer of IBM’s cloud-based Watson data processing resource. Similar kits exist for the Raspberry Pi.

IoT Cloud Services

Data collected by gateways across an IoT infrastructure must be processed, analysed, stored and made available for viewing anywhere on a connected desktop or mobile device. If appropriate, control data generated by this processing should be fed back through the gateways to actuators around the IOT’s edge. This can involve high volumes of sensors, actuators and gateways – think of a smart grid system measuring car circulation levels to control traffic lights across a city, for example.

An IoT installation of any size calls for a data centre equipped with the appropriate hardware, software, communications, environmental and security protection, and appropriately-trained personnel. Some organisations are willing to accept this overhead and set up a private cloud accordingly. For many others, however, a more attractive, affordable and scalable solution is to access shared resources from a public cloud service provider such as Microsoft or IBM. A useful variant, especially during growth periods, is to develop a hybrid cloud comprising both private and public elements.

The services can either be subscription-based, or metered (pay-per-use) for the tightest cost control. The three major service models for cloud computing are Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS). Their differences relate to how management of the various cloud hardware and software components is shared between the services vendor and user. The utilisation of the chosen cloud resources is unique to each application; off-the-shelf solutions are rarely if ever available. One approach is to work closely with a service provider to develop a complete turnkey solution, as Kone did with IBM. The agreement gives Kone access to IBM’s Watson IoT Cloud Platform to connect, remotely monitor and optimise its management of millions of elevators, escalators, doors, and turnstiles in buildings and cities worldwide.

Fig.4: Cloud service models