Best design practices for IoT device iteration
SaaS and agile development have paired to bring constant iteration to software for a while now. And the market is better for it, receiving new features and product updates as soon as they are available (versus the 12 or 18 month software release cycle when software shipped in a box.) IoT brings this ability to devices, giving developers the ability to iterate at will. Now we can update devices with new features and functions as part of the hardware device lifecycle. However, to maximize the ability to update configurations or add new functionality after the device has left the factory, developers have important upfront work to consider.
The first factor to think about is the bootloader as a well-designed bootloader enables iterative updates. All wireless SoCs come with some stock device firmware update (DFU) functionality. However, adding a couple of features to your bootloader will cut your update risk factors significantly, in many cases by up to 90%.
Separate bootloader
The first recommendation I give in this area is to separate the bootloader DFU from the main application firmware. By separating the two, you increase your chances of the device starting up regardless of the state of the application firmware. Recent IoT device DDoS attacks took advantage of passwords hardcoded into firmware to control the device. When rebooted, they bricked. Having a separate bootloader helps avoid this situation (as does good security and password hygiene).
Double buffer
A second best practice for iterative design is the inclusion of a double buffer. This gives you the flexibility to verify an update before it’s loaded on the device. Merely having a double buffer is not enough, however. Design engineers should plan ahead and make sure that the buffer is large enough to facilitate any potential updates. Given the wide variety of use cases I have seen, I’ve found that 500k is typically enough.
Encryption
The third best practice I recommend is end-to-end encryption. End-to-end is important here as security is only as good as its weakest link. Complete encryption protects you from a wide variety of events — from someone stealing your IP to malicious code attacks. While the recent rash of news coverage of things like the Cayla doll is unpleasant, security events in the food supply chain or medical devices could have extensive effects we all want to avoid.
As such, I advocate encrypting the update package all the way from a system you totally control to the IoT device itself. Don’t rely on the Bluetooth connection’s default encryption. Instead you should share the keys at the point of manufacture via a hardwire connection at the factory. This ensures that even if the connection is compromised, no rogue firmware can be loaded on the device.
Update at scale
Once you’ve designed your device for iteration, it’s also important to have a process and system for managing updates in the field and at scale. I recommend a device operation application that can talk with each device and has the ability to identify and group devices. For example, you may want to tag or group devices based on their functionality, or where they are deployed. With support for these tags within the firmware design and device operation application, you can easily group devices for updates. This eases the process of updating device features and functions.
Additionally, tagging like this allows you to tier and stagger rollouts which gives you more control over the process and reduces the risk of update failure. In fact, having participated on more than 100 IoT projects now, I highly recommend staggered rollouts. In these rollouts, admins incrementally update batches of devices and wait for a green light between each to ensure success.
Good update design also includes building in some fail-safes. As a parting tip, I recommend designers add logic to their bootloader DFU to do a checksum on the update. Verify it transmitted successfully before you write over the firmware image. Just like blue-green deployments in the DevOps world, move a copy of the original firmware to the buffer while the device reboots. If the new firmware fails, simply roll back to the earlier, working version.
The ability to update devices once they have left the factory is one of IoT’s biggest advantages. Ensuring that your device is designed for this level of iteration does take some upfront work. Yet it pays dividends in avoiding the potential costs of a security issue. And more importantly breeds customer satisfaction and business value as developers can deliver market-impacting features and functions at the speed of business.
All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.