The Path to Future-Proof IoT

The concept of the IoT has been laid out 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. It is important that 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 the path of 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. 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:

• ZigBee
• WirelessHart
• Bluetooth Low energy
• ZigBee IP
• Thread
• 6TiSCH
• LoRa
• Wi-Sun
• NB-IoT

We soon ended up with a problem of choice.

How Standards Proliferate

The Path to Future-Proof IoT: Source: XKCD

Each standard obviously has its own merits and weaknesses. These standards are sometimes tailored to specific application domains (such as smart city or building automation), and other times are totally application-agnostic. The only thing we know for sure is that some of these standards will cease to exist in the future. Along with that, new, superior ones will appear. Quite inevitably, the IoT will converge to a small subset of standards. How do we start building now, at a time when things have not yet converged, but 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 to reach the market early, while still having the ability to improve on the product later on.

A particularly challenging aspect of OTA upgrading is how to deal with the evolution of the protocol stack itself. There exist two main approaches to this challenge, which can be combined.

The First Approach: Issue Backward-Compatible Firmware

Each new version of the firmware includes support for both the old and the new protocol stack. As the new protocol is rolled out, you can start obsoleting the old one and remove dual-protocol support in future revisions. This is an elegant approach, but it is unfortunately costly and not always practical. Implementing and maintaining backward compatible software is hard. In certain cases, it cannot be afforded at all, perhaps due to constraints in firmware size for example.

The Second Approach: Include a Fallback Mode for Upgrades

It is wise to add a primitive way to upgrade your firmware from the very first versions of your product, no matter how subsequent protocols turn out to be. This is typically done by having the device enter a safe mode via some manual action. The user then brings the device in direct range to a gateway or upgrade station and issues the upgrade over a simple communication protocol that is not meant to evolve much (if at all) over releases. This solution provides a nice anti-bricking insurance.

The Path to Future-Proof IoT: Source: 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 said upgrades into 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 already have in mind in the first iterations of your product. One such concern is that you must make sure that only you can issue new software to your products. This is done with signed binaries verified at boot-time, ideally with secure boot and public-key infrastructure.

Another challenge is to protect your product against supply-chain attacks. In a supply-chain attack, 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 off the Device

Let’s turn our attention to the 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 need not 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's 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 a 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, rather than 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-ness. Building on standards means you have as close to a guarantee as possible 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 design choices, bug detection, security leaks, etc. compared to the capacity available 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 that 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 builds 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, it may be hard to find active communities. When using open-source, choose wisely.

The Path to Future-Proof IoT: 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. Favor versatile radio chips over specialized ones. Some chips can even run multiple protocols, sometimes simultaneously. Having the ability to plug in external sensor elements can also make a lot of sense for future-proof-ness, 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 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 one of the things that makes IoT such an exciting field!