20 Things to Consider When Planning an IoT Solution - Part 2
Date: Jan 17, 2019
Author: Aaron Fulton, Systems Developer
Part 2
This post is Part 2 of a 2-part series on what to consider when planning an Internet of Things (IoT) solution.
As we discovered in Part 1, IoT is a complex subject which crosses many disciplines ranging from embedded electronics through to communications, cloud infrastructure, and software design. Architecting an IoT solution is a multifaceted business, there are many things to consider. For most organisations, working with companies who have IoT experience is critical to architecting and implementing a solution which works on all levels. IoT crosses 4 key domains: Devices, Communications, Cloud/Server infrastructure, and Applications.
In Part 1 we looked at some higher-level aspects to consider. In this article, we'll take a deeper look at some of the more technical hardware-related aspects.
11. Power & Battery Life
Power is a major consideration for IoT devices. Electronics need power to operate and this must come from somewhere. There are really only three mainstream options: mains power, solar power, and battery power. Where the IoT solution is deployed will dictate what type of power is available, and it is from this that a lot of other decisions are based. Sensors require power, computation requires power, and communications require power. Typically IoT devices are battery powered and need to last a really long time (many years). This means that the battery has to be really good and the power consumption needs to be really low. This presents an engineering challenge. Batteries not designed for this purpose can suffer from self-discharge and this can dramatically affect the life expectancy of the solution. There is a huge range of batteries on the market now and choosing the right one is very important.
12. Communications
The communications platform is a key decision. When it comes to communications there is a triad of inter-related factors. Range, Bandwidth, and Power consumption. Each communications technology has different range characteristics. Some technologies can jump directly onto the internet while others need some kind of hub or gateway. It is important to choose the communications protocol that is fit for purpose.
13. Transmission Rate & Quality of Service
Another important aspect of communications is the transmission rate and quality of service. Protocols that operate on free radio spectrum have "good behaviour" restrictions placed on them. These restrictions are like "fair use policies" and limit how often devices are allowed to transmit. As a consequence, the amount of data that can be sent from protocols such as LoRa or Sigfox is limited to at most a handful of small bursts of data every few minutes. For sensors that just need to send in periodic readings such as measuring the office temperature, this is perfectly adequate but for more critical applications (such as monitoring the temperature in a cool store) this is not good enough.
How important is it for messages to get through? This is where quality of service (QoS) comes in. Due to the "good behaviour" restrictions, it is not feasible to send acknowledge messages back to the devices after every transmission. This means that often data needs to be sent with the hope (not guaranteed) that it will be received. For applications that do not require every single piece of data to make it through the journey that is fine, but for more critical applications the quality of service can be a real issue. Not all protocols suffer from the quality of service problems, so careful selection is needed.
14. Two-way Communications
Do you need to talk to the device? If so, how real-time does that need to be? The main way that devices are made low power is by sleeping. Much like with humans, talking to devices in their sleep is not a very effective way of communication - you need to make sure they are awake first. Low power devices wake themselves up and do what they have to do (usually taking a reading from a sensor and transmitting it). There is then usually a small window after the transmission when low power devices "listen". It is a really difficult engineering problem to have low power devices for applications that need to control stuff in a timely manner.
Figure 1: Communications Networks Comparison spider graph as of July 2018 (Graph made by BSL)
* Commercial networks are not yet fully deployed therefore coverage for NB-IoT and LoRa WAN is marked as low. For the same reason, some other evaluations are based on information at hand rather than measured performance.
15. Network Selection & Availability
Communications networks are not ubiquitously available. Cellular providers use terms like "Our mobile network covers over 98.5% of the population" which is code for, we've got the main centres covered really well and rural coverage is spotty. It is likely that LoRa WAN, NB-IoT and SigFox will be similar in their approach. It only makes economic sense to deploy to places where there are enough people to make the network financially viable. Some networks like Wi-Fi and LoRa can be rolled yourself but with that comes the burden of maintenance.
16. Remote Updates
How good is the firmware on the devices? Will it ever need to be updated? Updates might be necessary to fix bugs, apply security patches, and add new features. Due to the limited downstream capabilities (server to device) of low power networks, remote firmware updates at this point in time are not possible. This means that the firmware on the devices needs to be rock solid at the time of installation. If remote update capability is needed, then a higher power communications protocol is required
17. Data Storage Policy & Quantity
IoT devices can create a lot of data. Consider a device that takes one single reading every 10 minutes; that is 4,300 readings every month. By the time data is stored in a database this would be around 2.5 MB of data growth every year. Now multiply that by a deployment of 1,000 sensors and you have 2.5 GB of database growth every year.
Now, if instead of one reading every 10 minutes, the application had 10 sensors. That is now 25 GB of database growth every year. While this in-and-of-itself is not a problem, but it must be planned for. Databases can become a challenge when they get this large. Cloud infrastructure is really good at dealing with scale and should be the default go-to for any large IoT application.
Data storage policies are also important. How long should the data be kept for? Does all the raw data really need to be kept for 10 years? Or can some of it be deleted sooner?
18. Data Quality, Accuracy, Integrity
Data quality must also be considered. Is near enough good enough or is a high degree of accuracy needed. For applications measuring consumables like water, power or gas, the data must be good enough to bill from. Sometimes sensors or devices can have a bad day and send in poor quality data and this must be considered, for example, something as simple a spider crawling into a height-measurement sensor could cause a blip in readings. Accuracy is also a consideration. Do readings need to be good to 10 cm or 1 mm? Data quality, like all quality, is something that does not happen by chance. It must be engineered in.
19. Edge vs Cloud Compute
There is a trade-off between putting compute on the edge (where the devices are) or in the cloud. On one hand, it is really convenient to do all the data processing in the cloud, the software can be updated easily, and all the data is kept centrally. However, there is no off-line capability when there is invariably a network outage. Doing all the processing in the cloud also means more data to transfer (which comes at a cost) and more cloud compute costs. On the other hand, doing as much processing on the device as possible means that there is a lot more resiliency to internet outages and the devices are more self-managing. Doing computing on the devices is also free as the processor is probably not fully utilized. However, edge computing does not work if one of the constraints is to conserving as much resource (battery) as possible to prolong life.
In practice, a compromise between the two needs to be reached. Usually, there is some data processing capability on the devices, but anything complex gets outsourced to a server in a far-off data-centre.
20. Sensors
Finally sensors. What would IoT be without sensors? Sensors are why the Internet of Things exists in the first place. Without a way of capturing interesting data the rest of the system is redundant. Good quality, robust and resilient sensing is one of the hardest parts of the whole IoT thing. While many things are interesting to measure, they are not always easy to measure. Sensors have to work in the harsh environment of the real world and need to be engineered appropriately. There is usually a few options for sensor types which could be used to measure something, each with their own set of pros and cons. Talking to sensing experts like Beta Solutions is a really important step in putting together a successful IoT project and getting the right data.
