Design methodologies for next-gen IoT sensors

The paradigm of 'big data' springs from an increasingly connected world through the rise of social media and business transactions. The prominence of the Internet of Things (IoT) will continue to strain the resources of the internet by a convergence of wireless sensor networks that generate massive amounts of data. It is projected that by the year 2020 there will be 20 billion devices connected to the internet with each individual having an average of 6.58 connected devices [1].

The IoT sensor backplane is increasingly expected to monitor the system under test on a real-time basis. This is true for IoT sensor solutions monitoring body area networks, safety and security solutions, industrial factory and process automation solutions, and building automation solutions to name a few. This gives rise to a new paradigm tied to the data collected by the connected devices, that of 'big data sensing.'

Big data sensing drives a rethinking of the way this data is managed. The concept of edge computing tries to address these issues by processing the data at the point where the connected device uploads the data to the network. This fails to consider the system as a whole where in addition to minimising the amount of data on the network, the overall power consumption of the wireless sensor network needs to be minimised in order to maintain acceptable battery life. In industrial IoT solutions for example, battery life of 10 years is typically expected for the connected device. Requiring the connected device to stream data real time to the network drives resources from the end node, which reduces the battery life of the device.

A more power efficient approach would be to process the data at the point of collection. Here, the IoT sensor will have to act autonomously from the gateway, initiate data collection on statistically significant events, operate with minimal power consumption, drive efficient means of extracting data, and only initiate transfer of data under instances deemed to be statistically significant. Minimising the occurrence of these data transfer events to the gateway reduces the amount of allocated resources by the network and leads to the most efficient solution. In this article, we take a holistic view of the IoT sensor solution and discuss design methodologies that address the system and module requirements which enable the connected device to operate autonomously with the lowest power consumption for real-time monitoring of the system under test.

Connected device power efficiency
We begin by analysing the power efficiency of a typical connected device in an industrial application. The device wirelessly monitors flow of liquid in a typical industrial process control solution. The block diagram shown in figure 1 consists of a low power microcontroller for processing of the data and resource management, an RF transceiver, a data logger, sensing module and an LCD display. Using a sub-system energy consumption model, the total energy consumed by the connected device is given by the following equation:

E_Tot = E_{MCU total} + E_sensor + E_listen + E_t + E_r + E_sleep + E_switch + E_LCD (Eqn 1)

where E_{MCU total} represents the total energy consumed by the microcontroller during active and sleep modes, E_sensor represents the energy consumed during sensing and E_LCD is the energy consumed by the display. The overall energy consumption during RF communication is the sum of the energy required during transmission (E_t) , the energy required to receive data from the gateway or adjacent nodes (E_r) , the switching energy going from idle and active states (E_switch) and the listening energy and energy required to resolve anti-collision during transmissions (E_listen). The IEEE 802.15.4 standard [2] MAC and PHY layers call for a standard CSMA (carrier sense multiple access) procedure for resolving anti-collisions. For this analysis we only consider the RF energy consumption associated with the MAC and PHY layer and do not account for additional overhead driven by the upper OSI layers of the RF protocol. In addition, we do not account for beacon events called out in the MAC layer.