Back to articles
The scale of commercial IIoT solutions is a very important factor to consider when deciding which wireless connectivity protocol to use.
While technical requirements can help in the choice of the wireless connectivity solution, e.g. low-power WAN or mesh technologies for large scale IoT networks, the final decision is likely to be made due to operational considerations.
Read more on our reaourse page: Industrial IoT
The amplification of issues at scale
When deploying large-scale networks, the impact of even a small change to a device will get amplified because of the scale of the network.
If you’re a developer working with industries that are relatively new to the concept of large-scale networks, they are less likely to be aware of some of the things that will impact on complexity and cost.
As with my last blog, here is a set of questions to consider when choosing a wireless connectivity protocol for a large-scale Industrial IoT solution.
The required quality of service
How long you can tolerate a problem in your network will dramatically affect operations. If it's not possible to send a team on-site quickly enough, it is better to choose a more robust connectivity solution or add redundancy.
How critical is the end system and are outages acceptable? In an airport, if the ‘smiley face’ feedback system breaks, it’s not critical. For sensors monitoring flow rates in a nuclear power plant, on the other hand, then that’s an outage that could cause a serious problem and for which you will need to arrange a quick fix.
Depending on the criticality, you may need to tune your design accordingly, including which connectivity solution to adopt. Compared to Zigbee, WirelessHART has so far been the preferred choice for industrial flow meters due to its robustness. That said, with new mesh technologies and new LPWAN solutions, the best connectivity solution for this application may soon change.
Is a single point of failure acceptable? If the network is critical, you may need to introduce redundancy in your system. Some mesh technologies have intrinsic redundancy for some aspects.
For example, Zigbee supports only one “coordinator”, which is responsible for forming the network and acting as Trust center and network manager. If that fails, the network loses some functionality, whereas a Thread network has the built-in capability to nominate the equivalent role.
Operational considerations
Once again, scale comes into play when considering operational factors. Designing a network with huge numbers of devices is all well and good, but someone still has to physically deploy, install and commission them. This needs to be as simple as possible, otherwise the costs of commissioning can rapidly outpace the hardware costs.
What is the impact/cost of not completing a commission? There will always be devices that don’t install properly for a variety of reasons. Designing a solution that is easy to install is mandatory. However, predicting the success rate of device commissioning is also crucial in managing a successful deployment and keeping costs under control.
> Read more: Secure IoT commissioning - how hard can it be?
If the cost of failure is high, consider the network design and how far away from a gateway or base station your individual devices need to be. Some technologies are far more predictable when it comes to signal strength than others.
The number and density of existing base stations in urban areas makes cellular IoT a ‘plug & play’ technology. This is not always the case for other LPWAN or meshing networks, where a proper planning is most of the times mandatory.
Maintenance considerations
What is the power source, and what is the impact of failure? When starting to think about the maintenance operations, the requirements on battery lifetime may change. For battery-operated sensors it is important to plan for replacement.
Are the sensors all in built-up areas, or are they remote? Is there easy and periodic access to the sensors? Is a backup required?
How dense is the network? Are there are other sensors nearby that can ‘step in’ while another’s battery is being replaced, or does redundancy need to be introduced to the network?
All these considerations may turn your design either more or less conservative, which will impact the type of connectivity, the type/size of battery, and the choice of SoC.
Firmware upgrades
We are all familiar with the fiddly nature of firmware upgrades with personal devices. Scale that up to one million devices, and suddenly operation issues become far from trivial.
Questions to ask:
- What if the sensor fails to perform the upgrade and stops working?
- What is the impact of having a slow firmware upgrade?
- Is it acceptable to have sensors on the network that haven’t all been upgraded?
- What is the cost of a manual upgrade?
It’s important to consider bandwidth. A higher data rate reduces the risks of the connection being interrupted during the update and minimizes power consumption. For critical networks, it could be good practice to equip each connected device with LTE-M capability, for its high data rate.
> Read more: Open cellular standards to drive IoT adoption
Small changes quickly add up
All these questions will impact the complexity and operating costs for the end user, impacting the total cost of ownership. Some of these costs may be hidden or even ignored during the design phase because it’s so easy to underestimate the impact that small, little changes or failures on the network can have at scale.
