Low power IoT design is challenging because a connected product comprises of hardware, firmware, software, and network. Add in power requirements, data message size, and data timeliness – it is clear that design must be carefully considered and optimized not only at the point of manufacture but also with consideration of field maintenance. I’m happy to share with you my perspective on how to get products quickly to market while reducing IoT design risk and maintaining maximum flexibility.
When the device is initialized by being powered up or restarted (button on the device) the program counter jumps to the Bootloader section of ROM memory and waits there for instructions. If there is no Bootloader the program counter will go to the start position of the flash memory (0000H) and start executing the instructions which are written – typically the main program flashed to the device.
The key to reducing IoT design risk is a well-designed Bootloader that updates functionality and configurations once the device is in the field. Tweet this
How to Create a Smart Bootloader
Most all devices will come with some stock device firmware update (DFU) capability. The following design elements will reduce your update risk factors substantially:
- Implement end-to-end encryption on to your devices. By end-to-end we mean encrypting the update package all the way from the distribution system all the way to the IoT device itself. You simply cannot rely upon the channel or protocols default encryption, instead, you should implement encryption keys. This ensures that rogue firmware cannot be loaded onto the device.
- The bootloader DFU should be outside of your main application firmware. By doing so the device can start up regardless of the condition of the application firmware.
- Be sure to always include a double buffer so that verification of updates can be done before their loaded. Bootloader capacity planning will define the size required to include projected growth.
Make bootloader updates as part of your DevOps process reducing human error of ongoing management and maintenance. Tweet this
Security First
As the IoT market consolidates only the paranoid will survive. Due diligence starts by considering how exposed you are if someone were to hack the actual device itself. This is because although you try to limit physical access to the device if someone is determined enough they will gain access.
An IoT solution should utilize Advanced Encryption Standard (AES) 128-bit encryption to secure the transfer of firmware to the unit and use device-specific encryption keys to further reduce the security footprint.
Managing Updates
Device updates should be managed through a central application. This is typically a cloud solution as part of an overall IoT platform.
This device operations management app needs to identify and group devices based off of their type, purpose, etc. most solutions do so through the use of metadata tags that will allow you to capture the various attributes of a specific device. The use of tags this makes feature management a lot easier, as you can define business rules through a combination of tag values.
The device operations management app should also have the capability to employ staggered rollouts which will reduce the risk of systematic failure due to a faulty update.
Differential Updates
Especially in the case of over-the-air(OTA) it is important to minimize the size and time of an update. This can be accomplished through what is called differential updating. A differential update contains only the changed parts of the firm wire and not the entire image itself.
A differential update can vary in its scope requiring anything from an entire library update or something as simple as a single line of code. This change management process can save as much as 80% efficiency versus monolithic firmware updates.
Failsafe Updates
A key element good design includes building in a failsafe. By adding logic into your Bootloader DFU you can add a checksum on the update and verify it was transmitted successfully before you ever update or write over the existing firmware image.
Is part of the failsafe process a copy of the original firmware is moved into that double buffer while the device reboots. If for some reason the firmware fails to boot successfully then the bootloader will swap out firmware images as part of a rollback strategy. Alerts and notification logic should be incorporated to notify the device operations management application when an issue occurs.
The failsafe process will need to be thoroughly tested to ensure that you’re not stuck in an infinite update loop.
Final Thoughts
If you need any help with the architecture or engineering of your IoT solutions, feel free to reach out to me.
