The Internet of Things, or IoT, is a collection of disruptive technologies. IoT is one of several tools for digitizing work methods and organizational processes. The Internet of Things market is fragmented, with various technical solutions solving problems across multiple market verticals. IoT solutions exist for almost every vertical, including industrial IoT, medical IoT, etc. In this article, we will focus on what is called Massive IoT, which I refer to as large-scale IoT. Large-scale IoT consists of, for example, sensors that generate data in large quantities, data that can provide insights, data that can be the basis for decisions and data we can use to change behaviour.
Smart sensors with edge intelligence
When iot-analytics.com analyzed trends for 2023, their top trend was smart sensors. It’s a reasonable choice. There is a lot to gain from smart sensors. Transmitting data over a wireless network costs more than processing the data locally. The costs of transmitting data can differ; not all costs are directly monetary, such as increased subscription costs and increased costs of storing measurements in a cloud service or on a server. The costs may also include increased power consumption in the sensor, resulting in shorter battery life and potentially more frequent battery changes.
Power consumption expectations
Energy consumption is important in applications with sensors. In these situations, you typically need to guarantee that your device will last 10+ years on one battery. Energy consumption is the holy grail of large-scale IoT. It is an easily explained product benefit – “our device will last ten years on one battery”. No one will question whether it is needed or whether it is realistic. But the IoT yardstick has created an expectation that every solution must be compared to. So how do you get there? Some of the battery life can be affected by filtering data in the device, by intelligent storage of data locally and by not uploading in real-time; three ways we can design functions in a smart sensor, and very much in line with the market trend.
I have been responsible for the overall design of the functions of an IoT sensor we developed (AKKR8). A relatively simple but necessary logic at the sensor level was designed from the insights that connectivity cost; problems are best addressed close to the network edges. Our sensor uses filtering of data. Once a measurement is taken, it decides whether to reject the measurement, store it, or upload the measurement value to the server. In simple terms, it can look like this.
We are installing a temperature monitoring sensor in a conference room. Not everyone is served by five-minute measurement updates of 20°C from a conference room. But the installed sensor will wake up and read the temperature. Say the measurement window for typical values is 20-21 degrees; then, the sensor will save this value in memory the first time. The second time it wakes up and measures, it is then 20.6°C, then it will save 20.6 in memory and discard 20.4. Suppose the concurring temperature measurements are within the 20-21 degrees range for a more extended period. If it is inside the limits, these measurements will be disregarded, and intermittently a select number of values will be uploaded, but only one value per a more extended time window. If the sensor wakes up and reads 18 degrees, we want it to pass this value on immediately to alert us that we are out of tolerance. In that mode, we can go into an alarm mode where we work with more frequent logging, which is stored locally, and sent up with more frequency. So with simple software functions, we can effectively save power consumption during transmission, space for local storage, and reduce the storage of unnecessary metrics in the cloud.
Less coverage, less battery life
We know that the less coverage a sensor has, whether it’s LoRaWAN or 4G/5G, battery life will be affected. It can be shortened by a factor of four in poorer conditions. By periodically having the sensor determine the signal strength of the connection and report it, we can have our central data analysis platform calculate a sweet spot for how often we can have the sensor send metrics based on the current signal strength.
How can we change and alternate the settings in the sensor? We let it read back such updates when it is still connected and has sent data. Say you use the MQTT data protocol. Then you can use so-called MQTT callbacks to let your sensor re-read updates if something in the configuration is to be changed. We have built ourselves to activate and deactivate functions remotely with callbacks. It can be about reading measurement values from additional sensors, controlling the frequency of measurement value updates, and more. This way, we can easily customize the function without updating the fixed software remotely. Using standard protocols, we can easily influence the characteristics of the sensors knowing that connectivity costs, so it’s all about adapting to the situation. MQTT is a rather rudimentary way to solve this; more power-efficient protocols or advanced ways exist. The sensors of the future will likely be able to adapt to the environment it is installed in. Let’s say a machine has a sensor attached to it that will monitor an electric motor for temperature and vibration. The sensor of the future learns how the machine behaves and what is not normal and can then set alarm limits for updating deviations. “This type of smart sensor will soon be around the corner, but in the meantime, we are working on how to save battery, money and the environment.
This article was first published in Swedish in Elektroniktidningen number 2 2023.