The idea of the IoT has been laid down for over 20 years. Yet the technology landscape is still very much under construction. New alliances, protocols, and platforms come every year, while others get abandoned. At Wittra we focus on building products that are relevant today yet won’t be obsolete when the next innovation comes around. This post describes our approach to building a future-proof IoT.
Ever-changing Technologies
From the early days of the IoT, it became clear that standards were going to be necessary if we were going to achieve massive object connectivity. Proprietary solutions would only get us so far in terms of scale and adoption. As siloed products simply are not able to achieve the network effects of open standard-based ones. This is why connectivity standards emerged rapidly, such as, to name a few:
- ZigBee
- WirelessHart
- Bluetooth Low energy
- ZigBee IP
- Thread
- 6TiSCH
- LoRa
- Wi-Sun
- NB-IoT
We soon ended up with a choice problem:
How Standards Proliferate
Cred. xkcd.com
Each standard obviously has its own merits and weaknesses. It’s sometimes tailored to specific application domains (such as smart city or building automation) and sometimes totally application-agnostic. The only thing we know for sure is that some of these standards will cease to exist in the future. And that new, superior ones, will appear. Quite inevitably, the IoT will converge to a small subset of the standards. How do we start building now that things have not converged yet when time-to-market is everything?
Over-the-air (OTA) Upgradeability
Over-the-air (OTA) upgrades are essential for almost any IoT product. That is how you deploy new features, fix existing ones, and issue security patches. A great OTA system is what makes it possible for you to reach the market early. This while still having the ability to improve on the product later on.
A particularly challenging aspect of OTA is how to deal with the evolution of the protocol stack itself. There exist two main approaches to this challenge, and they can be combined.
The First Approach is to Issue Backwards-Compatible Firmware
Each new version of the firmware includes support for both the old and the new protocol stack. As the new is rolled out, you can start obsoleting the old, and remove dual-protocol support in the next revisions. This is an elegant approach but it is unfortunately costly and not always practical. Implementing and sometimes maintaining backwards-compatible software is hard. In certain cases, it cannot be afforded at all, for example, due to constraints in firmware size.
The Second Approach is to Include a Fallback Mode for Upgrades
It is wise to add from the very early versions of your product a primitive way to upgrade your firmware. No matter how the next protocols turn out to be. This is typically done by having the device enter a safe mode via some manual action. Then bringing the device in direct range to a gateway or upgrade station, and issuing the upgrade over a simple communication protocol that is not meant to evolve much or at all over releases. This solution provides nice anti-bricking insurance.
Cred. bonkersworld.net
No matter the approach(es) you select, your OTA system must be incredibly reliable, or else you risk losing devices in the field. Less intuitively, you also want your OTA system to be quick and fully automated. These upgrades are important because it means you can upgrade often and cheaply, and integrate it in your CI/CD workflow. This basically brings the DevOps best practices, and their benefits, to the IoT world. OTA upgrades bring their own set of massive security challenges, which you must have in mind already in the first iterations of your product. One is that you must make sure only you can issue new software to your products. This is done with signed binaries verified at boot time. Ideally with a secure boot and a public-key infrastructure.
Another challenge is to protect your product against supply-chain attacks. The attacker targets your continuous deployment pipeline to deploy malicious code into the products. Treat your supply chain as the critical component that it is. Apply security best practices such as enforcing two-factor authentication, using security tokens to sign the releases etc.
Application Logic of the Device
Let’s turn our attention to our system architecture itself, and how to make it future-proof. One key principle, which has led the Internet to its success, is the end-to-end principle. The end-to-end principle basically states that only end hosts need to implement a given application; other participants in the networks are application-agnostic.
On the Internet, this means you have a Web client exchanging with a server. But your access provider and core Internet router, do not need to know anything about what’s going on. This brings a key scalability advantage, as intermediate nodes do not need upgrading as the application evolves. What’s more, for the Web, the logic basically lies entirely on the server side. The client is nothing but a generic browser, running code supplied by the server.
The IoT can benefit greatly from the same approach, for connectivity between wireless products and either the edge or cloud. If you have a wireless mesh network, keep the forwarding layer application-agnostic. Avoid in-network aggregation and cross-layering. Keep the gateway as thin as possible, so that it knows as little as possible about the application. If you have an edge architecture, keep the end-to-end principle strict from edge to device. Edge nodes often need to know about the application. And that’s manageable because they are directly connected to the Internet and are in your control.
It’s a good idea to have as much of your application logic as possible at the cloud or edge. Not in the IoT device itself. This is simply because the device is by far the hardest and riskiest to upgrade. This also eases CI/CD, as simpler devices are simpler to mock.
Avoid Technical Lock-in for your Standards/Technology
In most markets, standard compliance is a must; but it will also benefit your product’s future-proof. Building on standards means you nearly have a guarantee that there will exist long-term maintained open-source implementations of the components and tools you need. This means you can spend less time building infrastructure protocols and focus on your application. When the time comes, you can port your application to a different stack if necessary.
By using standard protocols, you have a whole community to rely on for things like a design choice, bug detection, security leaks etc., compared to the capacity within one single company. The more something is used the higher likelihood it will remain and still be maintained in 20 years from now. Think of how nice it is in other areas where things are standardized. Like the fact that you can buy a USB-C cable in many different stores and that it works with a great number of devices.
Generally speaking, avoid technical lock-in. Relying on one single vendor solution and building your solution around it would build a stronger and stronger dependency on that company. This is a risk because what you want today might not be what you want tomorrow.
Open source is used more and more within IT companies. Even big players like Microsoft have in the past years embraced the power of open-source software. What you discover fast in the IoT sphere, however, is that it is still a very immature market. Hence hard to find active communities. When using open source, choose wisely.
Cred. xkcd.com
Future Proof IoT – Dealing with Hardware
Hardware is the one component in your system that obviously can’t be upgraded remotely. For this reason, in the ever-changing IoT world, it’s a good idea to avoid any early optimization in this area. To the extent where you can afford it (cost and battery-wise for example), having hardware that can do a little too much is better than the opposite. For example, do not hesitate to include a TPM or an accelerometer even if you have no short-term plan to use them. Prefer versatile radio chips over specialized ones. Some chips can even run multiple protocols, sometimes simultaneously. Having the ability to plug external sensor elements can also make a lot of sense for future-proofing, depending on the market you’re in.
This will postpone the day you have to upgrade your hardware and lengthen your product lifetime. Once you do have to upgrade the hardware, you’ll benefit again from the software guidelines discussed above. No technical lock-in and good open-source communities mean it should be easier to port your software to a new chip or radio.
Takeaway of the Path to Future-Proof IoT
The main challenge in IoT is to achieve a short time-to-market in a future-proof manner. We believe it can be done. As long as you build your product with upgradeability, modularity, and standard compliance in mind from the beginning. The fact that we have to focus so much on best practices and software quality is something that makes IoT such an exciting field! Wittra® technology has gained significant traction in the IoT industry and received several prestigious awards for its ground-breaking technology in location intelligence. See how we future-proof IoT. Read more about us here!
